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

[Duncan Sands]

Hi Renato,

> On 14 April 2012 20:34, Duncan Sands<baldrick at free.fr>  wrote:
>> the verifier checks that the accuracy operand is either a floating point
>> number (ConstantFP) or the keyword "fast".  If "Accuracy" is zero here
>> then that means it wasn't ConstantFP.  Thus it must have been the keyword
>> "fast".
>
> I think it's assuming too much. If I write "foobar", it'd also work as
> "fast", or even worse, if I write "strict"...

if you use "foobar" the verifier will reject your IR as invalid.  That said,
I'm not in love with the word "fast" here.  Maybe "finite" would be better.

> I'm not an expert in FP transformations, but as Dmitry said, there
> could be more than one "fast" transformations.

There's a difference between transformations that interact properly with
NaNs and infinities (eg: x + 0.0 -> x) and those that don't (eg: x * 0.0
-> x).  There is also a difference between those that introduce a uniformly
bounded (in the inputs) relative error, and those for which the relative
error introduced can be arbitrarily large depending on the inputs.  I have
in mind the uniformly bounded relative error ones, preserving NaNs and
infinities.  I guess I should say that explicitly in the LangRef changes.

  Maybe that should be an
> enum somewhere, rather than an accuracy.

I'd rather introduce additional operands in the fpmath metadata.

> Can you accurately propagate accuracy ratios across multiple
> instructions? Through multiple paths and PHI nodes? Not to mention
> that the "Accuracy" is also FP, which has its own accuracy problems...
> sigh...

I don't understand the question.  The metadata applies to one instruction,
the accuracy loss is per instruction.  A transform that introduces a relative
error of 2.5 ULPs per instruction can of course result in a huge accuracy loss
after a huge number of instructions.

Ciao, Duncan.