<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Nov 30, 2015 at 7:24 PM Gao, Yunzhong <<a href="mailto:yunzhong_gao@playstation.sony.com">yunzhong_gao@playstation.sony.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">According to <a href="http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html" rel="noreferrer" target="_blank">http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html</a>,<br>
"The high-order double-precision value (the one that comes first in storage) must have the larger magnitude."<br>
<br>
So the order of the two doubles in your fp128 is not affected by the endianness; although each individual double is.<br></blockquote><div><br></div><div><div>Well I'm still trying to understand the code base, so I may get this completely wrong, but here is my understanding:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><br>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."</div></div></div>