[LLVMdev] customized output of double load/store on ppc32

[Eli Friedman]

On Wed, Jul 23, 2008 at 5:05 PM, Scott Graham <scott.llvm at h4ck3r.net> wrote:
> On Wed, Jul 23, 2008 at 4:46 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Wed, Jul 23, 2008 at 4:23 PM, Scott Graham <scott.llvm at h4ck3r.net> wrote:
>>> I'm using the PPC backend's output as the "bytecode" for an interpreter
>>> that I would like to be able to run on both little- and big-endian
>>> platforms. The split stw's mean that i32s of the f64 are swapped in
>>> memory on little-endian (thus foiling native-code interop).
>>
>> It's fundamentally impossible to correctly interpret using the wrong
>> endianness, at least for general C code.  Have you considered making
>> your interpreter map memory backwards on opposite-endian platforms?
>
> Hi
>
> The front-end is not C code, and doesn't do bit-level operations (if
> that's what you mean).

Sort of, yeah... constructs like union {double a; unsigned b[2];} in C
depend on the endianness.

> But, I'd like to
> support an FFI to native code (which of course doesn't have any
> knowledge of having to swap memory), so that isn't too practical.

You can't do FFI with incompatible ABIs in the general case without
copying the data into structures appropriate for the target.  Structs
are laid out differently on different architectures, and sometimes the
incompatibility is non-obvious.  But I'll assume you're doing some
simple case, like the arguments being only scalars and pointers.

Back to your issue, the simplest workaround for particular issue of
splitting stores is to mark all your stores volatile; that will force
the store to be done in a single instruction (the price is that it
will reduce the effectiveness of some optimizations, but it shouldn't
have a huge impact if you restrict it to the arrays you're going to
pass via FFI).  If you prefer to hack your version of LLVM, you could
alternatively disable the relevant optimization... it's probably in
DAGCombine or PPCISelLowering, although I haven't checked.

-Eli