[PATCH] D15120: Add support for __float128 type to be used by targets that support it

Hubert Tong via cfe-commits cfe-commits at lists.llvm.org
Wed Feb 10 08:16:47 PST 2016


hubert.reinterpretcast added inline comments.

================
Comment at: lib/Sema/SemaExpr.cpp:1169
@@ +1168,3 @@
+  if (LHSElemType == S.Context.Float128Ty &&
+      RHSElemType == S.Context.LongDoubleTy)
+    return true;
----------------
nemanjai wrote:
> hubert.reinterpretcast wrote:
> > I do not believe that the width of `long double` is sufficiently established to be the same as that of `__float128` in this context.
> This would certainly cause any attempts to convert between some different implementation of **`long double` **(i.e. the Intel 80-bit type). I believe that this behaviour is desired in all cases where **`long double`** and **`double`** have a different representation. Namely, we do not currently have any support for converting between **`fp128`** and anything that has precision >= **`double`** that is not actually **`double`**.
> 
> What I propose to do here and in other locations where we diagnose conversions between the two types is that the check is:
> - One type is `__float128`
> - The other is `long double`
> - The representation of `long double` is not `llvm::APFloat::IEEEdouble`
> 
> Basically in this function, the early exit path would be:
> - representations are the same or
> - representation of `long double` is `llvm::APFloat::IEEEdouble`
This really sounds like a property of the target. The situation described in D15120#inline-141210 is similar.

I would not want to do a virtual function call without early exits here. So, perhaps the `TargetInfo` should be queried only at the point where we would otherwise return `true`.

I can't say that I like the name of this function now. Perhaps `unsupportedTypeConversion`?


Repository:
  rL LLVM

http://reviews.llvm.org/D15120





More information about the cfe-commits mailing list