[llvm-dev] Endianness for multi-word types

Gao, Yunzhong via llvm-dev
Tue, 01 Dec 2015 03:24:51 -0000

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!