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

Evan Cheng
2012-10-30T22:11:26Z

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