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

[Evan Cheng]

On Oct 30, 2012, at 9:36 AM, Michael Ilseman <milseman at apple.com> wrote:

> 
> On Oct 30, 2012, at 1:46 AM, Duncan Sands <baldrick at free.fr> wrote:
> 
>> Hi Michael,
>> 
>>> 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
>> 
>> while the above flags make perfect sense for me, the other two seem more
>> dubious:
>> 
>>> allow fusion (F)
>>>  - fuse FP operations when convenient, despite possible differences in rounding
>>>    (e.g. form FMAs)
>>> unsafe algebra (A)
>>>  - allow for algebraically equivalent transformations that may dramatically
>>>    change results in floating point. (e.g. reassociation)
>> 
>> They don't seem to be capturing a clear concept, they seem more like a grab-bag
>> of "everything else" (A) or "here's a random thing that is important today so
>> let's have a flag for it" (F).
>> 
> 
> 'A' is certainly a bit of a grab-bag, but I had difficulty breaking it apart into finer-grained pieces that a user would want to pick and choose between. I'd be interested in any suggestions you might have along these lines.

There is cost in modeling property. Unless there are uses for the individual fine grained properties, we shouldn't go overboard.

Evan

> 
> Why is 'F' such a random flag to have? 'F' implies ignoring intermediate rounding when a more efficient version exists, and it seems fair for it to be its own category.
> 
>> ...
>> 
>>> Why not use metadata rather than flags?
>>> 
>>> There is existing metadata to denote precisions, and this proposal is orthogonal
>>> to those efforts. These flags are analogous to nsw/nuw, and are inherent
>>> properties of the IR instructions themselves that all transformations should
>>> respect.
>> 
>> If you drop any of these flags then things are still conservatively correct,
>> just like with metadata.  In my opinion this could be implemented as metadata.
>> (I'm not saying it should be represented as metadata, I'm saying it could be).
>> 
>> Disadvantages of metadata:
>> 
>> - Bloats the IR (however my measurements suggest this is by < 2% for math heavy
>> code)
>> - More painful to work with (though helper classes can mitigate this)
>> - Less efficient to modify (but will flags be cleared that often)?
>> 
>> Disadvantages of using subclass data bits:
>> 
>> - Can only represent flags.  Thus you might end up with a mix of flags and
>> metadata for floating point math, with the metadata holding the non-flag
>> info, and subclass data holding the flags.  In which case it might be better
>> to just have it all be metadata in the first place
>> - Only a limited number of bits (but hey)
>> 
>> Hopefully Chris will weigh in with his opinion.
>> 
>> Ciao, Duncan.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> Thanks for the feedback!
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev