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

[Evan Cheng]

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).
> 
> ...
> 
>> 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.

FYI. We've already had extensive discussion with Chris on this. He has made it clear this *must* be implemented with subclass data bits, not with metadata.

Evan

> 
> Ciao, Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev