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

[Dmitry Babokin]

On Sun, Apr 15, 2012 at 3:53 AM, Chandler Carruth <chandlerc at google.com>wrote:

>
>> 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.
>
>
> I actually lobbied with Duncan to use a function default, with instruction
> level overrides, but his posts about the metadata overhead of just doing it
> on each instruction, I think his approach is simpler.
>
> As he argued to me, *eventually*, this has to end up on the instruction in
> order to model inlining correctly -- a function compiled with '-ffast-math'
> might be inlined into a function compiled without it, and vice versa. Since
> you need this ability, it makes sense to simplify the inliner, the metadata
> schema, etc and just always place the data on the instructions *unless*
> there is some significant scaling problem. I think Duncan has demonstrated
> it scales pretty well.
>

For simple metadata, like "fast" in initial proposal, it could be ok. But
if more complex metadata is possible (like I've described), then this
approach could consume more bitcode size, than expected. And I'm sure there
will be attempts to add fine-grain precision control. And the first
candidate is probably enabling/disable FMAs.

Inlining is a valid concern, though inside the single module fp model will
be the same in absolute majority of cases. People also tend to have
consistent flags across the project, so it shouldn't be rare case when it's
consistent between modules.

Function or module level default setting is really just an optimization,
but IMHO quite useful one. It would also simplify dumps and understanding
of what is going on for people who don't want dig into details of fp
precision problems and be distracted by additional metadata.

Just to be clear. As it's not me, who is going to implement this, I'm just
try to draw an attention to the issues that we'll finally encounter down
the road.

Dmitry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120415/092808f2/attachment.html>