<div dir="ltr">+1<br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 10, 2015 at 12:36 PM Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">----- Original Message -----<br>
> From: "Owen Anderson" <<a href="mailto:resistor@mac.com" target="_blank">resistor@mac.com</a>><br>
> To: "llvm-commits" <<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a>><br>
> Sent: Friday, July 10, 2015 1:22:07 PM<br>
> Subject: Proposal: New Intrinsic anyfloat @llvm.canonicalize(anyfloat)<br>
><br>
> Hello all,<br>
><br>
> Below is a proposal for a new target-independent intrinsic<br>
> @llvm.canonicalize, primarily intended for use in the implementation<br>
> of numerically sensitive routines. Much thanks to Ian Ollmann and<br>
> Steve Canon for providing input on this proposal.<br>
<br>
I think this proposal makes sense.<br>
<br>
-Hal<br>
<br>
><br>
> —Owen<br>
><br>
> ------------------<br>
><br>
><br>
> @llvm.canonicalize returns the platform specific canonical encoding<br>
> of a floating point number. The canonical encoding is defined by<br>
> IEEE-754-2008 to be:<br>
><br>
> 2.1.8 canonical encoding: The preferred encoding of a<br>
> floating-point representation<br>
> in a format. Applied to declets, significands of finite<br>
> numbers, infinities,<br>
> and NaNs, especially in decimal formats.<br>
><br>
> This operation should be considered to be equivalent to the<br>
> IEEE-754-2008 conversion of a floating-point value to the same<br>
> format. NaNs are handled according to section 6.2.<br>
><br>
> Examples of non-canonical encodings:<br>
><br>
> x87 pseudo denormals, pseudo NaNs, pseudo Infinity, Unnormals.<br>
> These are converted to canonical representation per<br>
> hardware-specific protocol.<br>
><br>
> Many normal decimal floating-point numbers have non-canonical<br>
> alternative encodings.<br>
><br>
> Some machines, like GPUs or ARMv7 in NEON mode, may not support<br>
> subnormal values. These are treated as non-canonical encodings<br>
> of zero and will be "flushed" to zero of the same sign by this<br>
> operation.<br>
><br>
> Note: Per IEEE-754-2008 6.2, under default exception handling<br>
> SNaNs signal an invalid exception and the function shall deliver<br>
> a quiet NaN.<br>
><br>
> Rationale:<br>
><br>
> In some advanced floating-point functions it may be most efficient to<br>
> manipulate the bits in a floating-point value directly. An example<br>
> be the implementation of frexp(). In such cases, the code can be<br>
> simplified if non-canonical encodings can be removed by hardware in<br>
> advance.<br>
><br>
><br>
> The user can in principle do this himself by multiplying the value by<br>
> 1.0. Unfortunately, that operation is typically removed by a<br>
> compiler optimizer. @llvm.canonicalize is provided as a way to<br>
> signal to the compiler that this operation shall not be optimized<br>
> away.<br>
><br>
> Caution: This definition of ‘canonical’ varies between environments,<br>
> so the result is non-portable.<br>
><br>
> Implementation notes:<br>
> This function should always be implementable as x 1.0, absent<br>
> compiler optimization (removal) of the expression. IEEE-754<br>
> rules state that basic operations return the canonical result.<br>
> Likewise, divide by 1 and possibly minNum(a,a), depending on<br>
> implementation should work. In some circumstances, x + -0.0<br>
> will also work, provided that the machine is not in round to<br>
> -infinity rounding mode, in which case 0.0 + -0.0 would return a<br>
> non-conforming -0.0.<br>
><br>
> @llvm.canonicalize preserves the equality relation. That is:<br>
><br>
> (@llvm.canonicalize(x) == x) is equivalent to ( x == x )<br>
> @llvm.canonicalize(x) == @llvm.canonicalize(y) is equivalent<br>
> to x == y.<br>
><br>
> In addition, the sign of 0 SHOULD be conserved:<br>
><br>
> @llvm.canonicalize(-0) = -0<br>
> @llvm.canonicalize(+0) = +0<br>
><br>
> This may educate which method is used to implement the function.<br>
><br>
> Per section 6.2 the NaN payload bits SHOULD be conserved, except that<br>
> SNaNs are quieted per the usual methods or in environments in which<br>
> all NaNs are canonicalized to a single payload.<br>
><br>
> The operation can be optimized away if:<br>
><br>
> The result is not used.<br>
><br>
> The input is known to be canonical. For example, it was produced<br>
> by a floating-point operation which is required by standard to<br>
> be canonical, such as any math library function or basic<br>
> floating-point arithmetic operation.<br>
><br>
> The result is consumed only by (or fused with) other<br>
> floating-point operations. That is, the bits of the<br>
> floating-point value are not examined.<br>
><br>
> Since @llvm.canonicalize can raise the invalid floating-point<br>
> exception, the operation can not be optimized away unless the<br>
> implementation can prove that the argument is not a SNaN or the<br>
> program is not monitoring floating point exceptions (e.g. #pragma<br>
> STDC FENV_ACCESS OFF).<br>
> _______________________________________________<br>
> llvm-commits mailing list<br>
> <a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
><br>
<br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</blockquote></div>