[llvm-dev] Endianness for multi-word types

[Gao, Yunzhong via llvm-dev]

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