llvm dev - Jul 2008 - [LLVMdev] customized output of double load/store on ppc32

Hi

For .LL like:

    define void @Func()
    {
        %var1 = alloca double
        store double 0x40bb580000000000, double* %var1
        ret void
    }

ppc32 output is:

    ...
    lis 3, 16571
    ori 3, 3, 22528
    li 4, 0
    stw 3, 8(1)
    stw 4, 12(1)
    ...

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).

Can anyone suggest where I should look to lower this store differently?
(ideally by libcall-ing a function that takes 2 i32s).

thanks,
scott

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?

-Eli

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). My first attempt was indeed to just leave
memory in big endian and swap during loads/stores. 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.

thanks,
scott