[LLVMdev] [RFC] Extend LLVM IR to express "fast-math" at a per-instruction level
baldrick at free.fr
Tue Oct 30 01:46:47 PDT 2012
> 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.
More information about the llvm-dev