[LLVMdev] [RFC] Extend LLVM IR to express "fast-math" at a per-instruction level
evan.cheng at apple.com
Tue Oct 30 15:11:26 PDT 2012
On Oct 30, 2012, at 1:46 AM, Duncan Sands <baldrick at free.fr> wrote:
> Hi Michael,
>> 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
>> 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
> 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
> - 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.
> Ciao, Duncan.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev