[llvm-dev] Endianness for multi-word types

[Tim Shen via llvm-dev]

On Mon, Nov 30, 2015 at 7:24 PM Gao, Yunzhong <
yunzhong_gao at playstation.sony.com> wrote:

> According to
> http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html,
> "The high-order double-precision value (the one that comes first in
> storage) must have the larger magnitude."
>
> So the order of the two doubles in your fp128 is not affected by the
> endianness; although each individual double is.
>

Well I'm still trying to understand the code base, so I may get this
completely wrong, but here is my understanding:

Looking at the comment of TargetLowering::hasBigEndianPartOrdering, it
seems that, all "internal types" (e.g. ppc_fp128, i128) are assumed to be
little-endian, and for non-ppc_fp128 external values (raw register tuples
or memory), the endianness follows the data layout endianness; for
ppc_fp128 external values (a pair of float registers or memory chunk), it's
always "big-endian" due to the policy.

The problem is when we bitcast from ppc_fp128 to i128, do we exchange the
two registers? Today we do, because ppc_fp128 requires a mandatory
big-endian representation, but at the same time it's a i128, which is
interpreted as a little-endian 128-bit integer. That's why the combiner I
previously mentioned gets confused.

If we don't exchange the two registers, combiners are happy because they
get a little-endian view of the two doubles (e.g. the most significant bit
is indeed the sign bit); but if someone stores this casted i128 to memory,
the two words are in little-endian, which breaks the ppc_fp128 layout
policy. It also breaks the bitcast semantic: "The conversion is done as if
the value had been stored to memory and read back as type ty2."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151201/5d4ca491/attachment.html>