[LLVMdev] [RFC] Extend LLVM IR to express "fast-math" at a per-instruction level

[Dan Gohman]

Hi Micheal,

On Mon, Oct 29, 2012 at 4:34 PM, Michael Ilseman <milseman at apple.com> wrote:

> I
> Flags
> ---
> no NaNs (N)
>   - ignore the existence of NaNs when convenient
> no Infs (I)
>   - ignore the existence of Infs when convenient
> no signed zeros (S)
>   - ignore the existence of negative zero when convenient
>

Does this mean ignore the possibility of NaNs as operands, as results, or
both? Ditto for infinity and negative zero.

Also, what does "ignore" mean? As worded, it seems to imply Undefined
Behavior if the value is encountered. Is that intended?


> allow fusion (F)
>   - fuse FP operations when convenient, despite possible differences in
> rounding
>     (e.g. form FMAs)
>

What do you intend to be the relationship between this and @llvm.fmuladd?
It's not clear whether you're trying to replace it or trying to set up an
alternative for different use cases.

Is your wording of "fusing" intended to imply fusing with infinite
intermediate precision only, or is mere increased precision also valid?

unsafe algebra (A)
>   - allow for algebraically equivalent transformations that may
> dramatically
>     change results in floating point. (e.g. reassociation)
>
[...]

> Not all combinations make sense (e.g. 'A' pretty much implies all other
> flags).
>
> Basically, I have the below semilattice of sensible relations:
>   A > S > I > N
>   A > F
> Meaning that 'A' implies all the others, 'S' implies 'I' and 'N', etc.
>

Why does it make sense for S to imply I and N? GCC's -fno-signed-zeros flag
doesn't seem to imply -ffinite-math-only, among other things. The concept
of negative zero isn't inherently linked with the concepts of infinity or
NaN.


>
> It might make sense to change the S, I, and N options to be some kind of
> finite
> option with levels 3, 2, and 1 respectively. F and A could be kept
> distinct. It
> is still the case that A would imply pretty much everything else.
>
> N - no NaNs
>   x == x ==> true
>

This is not true if x is infinity.


>
> S - no signed zeros
>   x - 0 ==> x
>   0 - (x - y) ==> y - x
>
> NS - no signed zeros AND no NaNs
>   x * 0 ==> 0
>
> NI - no infs AND no NaNs
>   x - x ==> 0
>   Inf > x ==> true
>

With the I flag, would the infinity as an operand make this undefined?


>
> A - unsafe-algebra
>   Reassociation
>     (x + C1) + C2 ==> x + (C1 + C2)
>
  Redistribution
>     (x * C) + x ==> x * (C+1)
>     (x * C) + (x + x) ==> x * (C + 2)
>   Reciprocal
>    x / C ==> x * (1/C)
>
> These examples apply when the new constants are permitted, e.g. not
> denormal,
> and all the instructions involved have the needed flags.
>

I'm confused. In other places, you seem to apply that reassociation would
be valid even on non-constant values. It's not clear whether you meant to
contradict that here.

[...]

> -fp-contract=<value>
>   I'm not too familiar with this option, but I recommend that 'all' turn
> on the
>   'F' bit for all FP instructinos, default do so when following the
> pragma, and
>   off never doing so. This option should still be passed to the backend.
>

Please coordinate with Lang and others who have already done a fair amount
of work on FP_CONTRACT.


>
> (Optional)
> I propose adding the below flags:
>
> -ffinite-math-only
>   Allow optimizations to assume that floating point arguments and results
> are
>   NaNs or +/-Inf. This may produce incorrect results, and so should be
> used with
>   care.
>
>   This would set the 'I' and 'N' bits on all generated floating point
> instructions.
>
> -fno-signed-zeros
>   Allow optimizations to ignore the signedness of zero. This may produce
>   incorrect results, and so should be used with care.
>
>   This would set the 'S' bit on all FP instructions.
>

These are established flags in GCC. Do you know if there are any semantic
differences between your proposed semantics and the semantics of these
flags in GCC? If so, it would be good to either change to match them, or
document the differences.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121030/a649966a/attachment.html>