[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