[LLVMdev] Representing -ffast-math at the IR level

[Duncan Sands]

Hi Dmitry,

>     That's possible (I already discussed this with Chandler), but in my opinion is
>     only worth doing if we see unreasonable increases in bitcode size in real code.
>
>
> What is reasonable or not is defined not only by absolute numbers (0.8% or any
> other number). Does it make sense to increase bitcode size by 1% if it's used
> only by math library writes and a couple other people who reeeeally care about
> precision *and* performance at the same time and knowledgeable enough to
> restrict precision on particular instructions only? In my experience
> it's extremely rare case, when people would like to have more than compiler
> flags to control fp accuracy and ready to deal with pragmas (when they are
> available).

there is no increase in bitcode size if you don't use this feature.  If more
options are added it will hardly increase the bitcode size: there will be one
metadatum with lots of options (!0 = metadata !{ this, that, other }), and
instructions just have a reference to it.  So the size increase isn't like
(number of options) * (number of instructions), it is (number of options) +
(number of instructions).

> And, again, I think this should be function level model, unless specified
> otherwise in the instruction, as it will be the case in 99.9999% of the
> compilations.

Link-time optimization will sometimes result in "fast-math" functions being
inlined into non-fast math functions and vice-versa.  This pretty much
inevitably means that per-instruction fpmath options are required.  That
said, to save space, if every fp instruction in a function has the same
fpmath metadata then the metadata could be attached to the function instead.
But since (in my opinion) the size increase is mild, I don't think it is
worth the added complexity.

Ciao, Duncan.