https://bugs.kde.org/show_bug.cgi?id=386945
--- Comment #52 from Julian Seward <jsew...@acm.org> ---
(In reply to Mark Wielaard from comment #51)
> I tried this, but seem to hit the following in the host_ppc_isel.c backend:
>
> static HReg iselWordExpr_R_wrk ( ISelEnv* env, const IRExpr* e,
> IREndness IEndianess )
>
> [...]
> /* --------- LOAD --------- */
> case Iex_Load: {
> HReg r_dst;
> PPCAMode* am_addr;
> if (e->Iex.Load.end != IEndianess)
> goto irreducible;
>
> Either I am misunderstanding how the IEndianess is passed around, or it
> isn't actually possible to have a different endian load from the arch
> endianness.
To clarify: there are two options here:
(1) in the front end, generate an IR load with the same endianness as the
host, and then byte-reverse the vector in the IR.
(2) in the front end, generate an IR load with the opposite endianness as
the host.
The effect of (1) is that the load will arrive and be handled at the
back end no problem, and then the code generated from the swap-endianness
IR will .. well .. swap the endianness of the value.
Whereas with (2), an opposite-endianness-to-the-host IR load travels
through to the back end. At that point your options are:
(2a) directly generate an opposite-endian load, or,
(2b) generate a same-endian load, followed by code to swap the vector around.
So: (2a) is the most direct route. (1) and (2b) are essentially the same,
with the difference that (1) does the rearrangement in IR whereas (2b) does
the arrangement at the POWER instruction level (in the backend).
Personally I'd vote for (1) because (a) it's easier and (b) I am not sure
that Memcheck will work correctly when presented with opposite-from-the-host
endian loads/stores.
--
You are receiving this mail because:
You are watching all bug changes.
