yaxunl abandoned this revision. yaxunl marked an inline comment as done. yaxunl added inline comments.
================ Comment at: clang/lib/CodeGen/TargetInfo.cpp:2824 + // which is equivalent to 16 bit integer. We need this to interop with + // gcc where 16 bit integer is used in place of _Float16 or __fp16. + Lo = Integer; ---------------- pengfei wrote: > yaxunl wrote: > > pengfei wrote: > > > The GCC should take _Floatn as floating types, see > > > https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Floating-Types.html#Floating-Types > > > Can you provide the information how gcc uses as 16 bit integer for > > > _Float16? > > GCC does not allow _Float16 or __fp16 to be used for x86_64. > > > > HIP language allows _Float16 or __fp16 type to be used with x86_64. To be > > able to passing _Float16 or __fp16 values between C++ using gcc and HIP > > using clang, users often write code like this: > > > > > > ``` > > struct half_t { > > #ifdef __GNUC__ > > uint16_t x; > > #else > > _Float16 x; > > #endif > > }; > > > > void fun1(half_t x); > > ``` > > And usually fun1 is defined in HIP and compiled by clang to object file, > > then they call it in C++ which is compiled by gcc. Then the caller will > > pass half_t by register. However clang passes half_t by stack. This causes > > issue. > It looks to me this is a user scenario issue. You are using different types > between GCC and Clang. There's nothing surprised if they aren't > interoperable. You should use uint16_t in fun1 too instead of changing the > behavior of the floating type. > Changing type behavior is dangerous, you will result in backward compatiblity > problems. That's also the reason why we need a well-defined ABI :) That makes sense. Thanks. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D97318/new/ https://reviews.llvm.org/D97318 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
