[PATCH] Update llvm.sqrt, etc. error semantics
hfinkel at anl.gov
Tue Nov 12 12:00:49 PST 2013
Chris, et al.,
As a follow-up to this message from llvmdev: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-November/067557.html I'm proposing the following change to the error-handling semantics of the llvm.<libm function> intrinsics.
The primary motivation for this change is to normalize the definition of llvm.sqrt w.r.t. the other llvm.<libm function> intrinsics. The current definition, does not allow (sqrt + -fno-math-errno) to be vectorized into llvm.sqrt. The motivation behind the current definition, which produces undefined behavior for values < -0, was to enable optimizations without considering the effects on errno. This seems to predate our current method for modeling -fno-math-errno by marking the libm functions as readnone, and is now inhibiting vectorization. Also, forcing the frontend to produce llvm.sqrt directly in fast-math mode (the present work-around) has other negative side effects (PR17758 for example).
A secondary motivation is to make the language reference better reflect the properties of the actual implementation. Under many ISAs, the vector forms of these intrinsics, at least, do not affect errno or the floating-point exception bits like the scalar libm functions do. Reflecting this in the semantics of the intrinsics is a useful thing to do.
In addition to llvm.sqrt, the other intrinsics, which are currently defined to handle errors in the same way as the corresponding libm function, would have that text replaced by:
Calling any of these intrinsics with a value that would trigger an error
in the corresponding libm function causes the value of errno, and the state of
any portions of the floating-point environment used to record floating-point
exceptions, to be undefined.
I do not believe that any code change is necessary here; only a change to the documented semantics.
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 9694 bytes
Desc: not available
More information about the llvm-commits