[PATCH] D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics

Cameron McInally via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 1 09:07:43 PDT 2019


cameron.mcinally added inline comments.
Herald added a subscriber: jdoerfert.


================
Comment at: include/llvm/CodeGen/ISDOpcodes.h:307
+    /// unsigned integer. These have the same semantics as fptosi and fptoui 
+    /// in IR. If the FP value cannot fit in the integer type, the results are
+    /// undefined.
----------------
craig.topper wrote:
> pengfei wrote:
> > kpn wrote:
> > > craig.topper wrote:
> > > > Is this what we want from a strict implementation. "icc -fp-model=strict" goes out of its way to generate an invalid exception when the input type doesn't fit and the hardware can't generate an exception on its own. https://godbolt.org/z/ABU80i
> > > No, I don't think this is what we want. I'll remove that sentence.
> > I don't understand the behavior of icc here. SDM says this instruction can raise floating-point invalid exception when the result out of range. Why icc add the code to raise another divz exception?
> The instructions raises an exception based on a 32-bit result size. But the C code has a 16-bit result size. We need to generate an exception if it doesn't fit in 16-bits to match the C code. But the available instructions can't do that.
That seems like a hardware problem.

Does LLVM have a policy on fixing up hardware deficiencies? It's not obvious that we should care about the hardware doing the wrong thing.

@eli.friedman 


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

https://reviews.llvm.org/D63782





More information about the llvm-commits mailing list