[PATCH] D64746: Add constrained intrinsics for lrint and lround

[Eli Friedman via Phabricator via llvm-commits]

efriedma added inline comments.


================
Comment at: docs/LangRef.rst:15724
+mode is determined by the runtime floating-point environment.  The rounding
+mode argument is only intended as information to the compiler.
+
----------------
cameron.mcinally wrote:
> kpn wrote:
> > cameron.mcinally wrote:
> > > cameron.mcinally wrote:
> > > > kpn wrote:
> > > > > andrew.w.kaylor wrote:
> > > > > > We should describe what is returned if the value is too large to be represented as a long. The llvm.lrint doesn't do that either, but it should too.
> > > > > What do we want this to be? My draft copy of C99 says the return value is "unspecified". What does that translate to in LLVM-land? Is this listed in IEEE 754?
> > > > That should throw an Invalid exception. And I think we agreed in your other Diff that it should return a poison value.
> > > ```
> > > 7.2 Invalid operation 
> > > 
> > > <...snip...>
> > > 
> > > For operations producing no result in floating-point format, the operations that signal the invalid operation exception are:
> > > 
> > > i) conversion of a floating-point number to an integer format, when the source is NaN, infinity, or a value that would convert to an integer outside the range of the result format under the applicable rounding attribute
> > > ```
> > Poison only in the constant folding case, right? What about in the non-constant-folding case?
> > Poison only in the constant folding case, right? What about in the non-constant-folding case?
> 
> @eli.friedman
> 
> Besides the obvious flag raising, that would be undefined. It would be up to the hardware. 
LangRef defines the semantics of the IR; what the current version of the optimizer does or does not constant-fold, or otherwise optimize, is irrelevant.

llvm.experimental.constrained.llrint should probably do the same thing as llvm.llrint, whatever that is, if the rounding mode is the default.  If that somehow didn't get defined in LangRef, please make a separate patch for that.


================
Comment at: docs/LangRef.rst:15736
+      declare <inttype>
+      @llvm.experimental.constrained.llrint(<fptype> <op1>,
+                                            metadata <rounding mode>,
----------------
andrew.w.kaylor wrote:
> It seems like we have a problem here. The intrinsics are overloaded to take any integer as a return type, but not all integers will match up with a real library call. Is that handled anywhere?
If you try to call an intrinsic where there is no underlying library call, it'll fail to compile, I assume.  This doesn't really seem like a problem.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D64746