[PATCH] D109950: [Clang] Enable IC/IF mode for __ibm128

[Qiu Chaofan via Phabricator via cfe-commits]

qiucf added a comment.

In D109950#3101740 <https://reviews.llvm.org/D109950#3101740>, @rjmccall wrote:

> Thanks.  @hubert.reinterpretcast, @qiucf, can you verify that other compilers for PPC follow the logic for `TF` / `TC` that we now have with Elizabeth's patch?  There are three different type specifiers (`long double`, `__ibm128`, and `float128_t`) which represent formally distinct types, and IIUC there are a bunch of different flags and target options that change the meaning of `long double` and/or disable/enable `__ibm128` and `float128_t`.  We care about exactly which type is produced by the mode attribute, so you'll have to do something which is sensitive to the exact formal type, like `_Generic` or a C++ template or doing a pointer conversion without a cast; checking code generation will only tell us the underlying format.



  typedef float __attribute__((mode(TF))) __tf128;
  typedef float __attribute__((mode(IF))) __if128;
  
  void foo() { printf(__func__); }
  void bar() { printf(__func__); }
  #define TEST(x) _Generic(x, __ibm128: foo, default: bar)()
  
  int main() {
    __if128 x;
    __tf128 y;
    TEST(x);
    TEST(y);
  }
  
  // GCC (long double=ieee): foobar
  // GCC (long double=ibm): foofoo
  // Clang (both): foobar

As discussed in https://reviews.llvm.org/D93377#inline-874356 , GCC and Clang handles them differently: in GCC `__ibm128` or `__float128` is alias to `long double` under appropriate option, but Clang sees them as different types. While for explicit mode, Clang thinks `float __attribute__((mode(IF)))` and `__ibm128` are the same type. The patch doesn't change the behavior.

By the way, for x86 `__complex128 check(__complex128 a, __complex128 b) { return a+b; }`, GCC seems to generate two `___addtf3`, while Clang generates `faddp`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109950/new/

https://reviews.llvm.org/D109950