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

Of this part it's pretty clear, so I guess my questions are, more
specifically:
1) Why


> Hope that helps,
> - Gao
>
>
> ________________________________________
> From: llvm-dev [llvm-dev-bounces at lists.llvm.org] on behalf of Tim Shen
> via llvm-dev [llvm-dev at lists.llvm.org]
> Sent: Monday, November 30, 2015 7:17 PM
> To: llvm-dev at lists.llvm.org
> Subject: [llvm-dev] Endianness for multi-word types
>
> Hi,
>
> I'm recently trying to investigate ppc_fp128 related problem. Here is a
> minimal C++ test case that seems wrongly compiled:
>
> long double id(long double a) {
>   return a;
> }
> bool f(long double x) {
>   return id(__builtin_fabsl(x)) >= 0;
> }
> int main() {
>   if (f(-123.l)) {
>     return 0;
>   }
>   return 1;
> }
>
> The program compiled with command:
> clang++ -static -target powerpc64le-linux-gnu bad.cc
> Returns 1 on a ppc machine.
>
> I did some investigation, it turns out in
> lib/CodeGen/SelectionDAG/DAGCombiner.cpp, a combination is wrongly assuming
> the endianness for the i128 bitcasted from a ppc_fp128 (two doubles
> bit-concatenated together):
>   // fold (bitconvert (fabs x)) -> (and (bitconvert x), (not signbit))
>
> This reveals that endianness conversion concerning ppc_fp128 or i128, and
> big-endian or little-endian target is too confusing to me.
>
> I can certainly fix this case by using a "smarter signbit" (e.g.
> 0x00000000000000001000000000000000), but this seems more confusing. I
> wonder if anyone has the best background knowledge here?
>
> Background I found:
> http://llvm.org/klaus/llvm/commit/1ef2cec146099f4bf46c31b913c7f1538935a867/
>
> Thanks!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151201/3d2761a2/attachment.html>