jcranmer-intel added inline comments.
================ Comment at: clang/lib/AST/Interp/Floating.h:27-29 + template <unsigned ReprBits> struct Repr; + template <> struct Repr<32> { using Type = float; }; + template <> struct Repr<64> { using Type = double; }; ---------------- tbaeder wrote: > jcranmer-intel wrote: > > aaron.ballman wrote: > > > Er, how will this extend to `long double` where the number of bits is > > > rather more difficult? > > Or `half` and `bfloat`, which are both 16-bit floating-point types? > I have spent some time with this today and tried to simply always use > `APFloat` instead of a primitive type. Unfortunately that doesn't work > because what we put on the stack is not the `Floating` (or `Integral`), but > the underlying primitive type. So even if we do the final math (in `::add`, > etc) via `APFloat`, we need something we can serialize to `char[]` so we can > put it on the stack. Do you think that would work? I don't know enough about the structure of the bytecode interpreter here to say for sure, but this smells to me like you're baking in an assumption that every primitive target type has a corresponding primitive type on the host. This assumption just doesn't hold when it comes to floating point (only two of the seven types, `float` and `double`, are generally portable, and even then, there be dragons in some corner cases). If you do need to continue down this route, there are two requirements that should be upheld: * The representation shouldn't assume that the underlying primitive type exists on host (bfloat16 and float128 are better test cases here). * Conversion to/from host primitive types shouldn't be easy to accidentally do. (Worth repeating again that bit size is insufficient to distinguish floating point types: `bfloat` and `half` are both 16-bit, PPC `long double` and IEEE 754 quad precision are both 128-bit, and x86 `long double` is 80 bits stored as 96 bits on 32-bit and 128 bits on 64-bit.) CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134859/new/ https://reviews.llvm.org/D134859 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits