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

[Chandler Carruth]

On Sun, Apr 15, 2012 at 3:50 AM, Dmitry Babokin <babokin at gmail.com> wrote:

> 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.
>

And I don't disagree, I just think it is premature until we have measured
an issue with the simpler form. Since we will almost certainly need the
simpler form anyways, we might as well wait until the problem manifests.

The reason I don't expect it to get worse with more complex specifications
is because the actual metadata nodes are uniqued. Thus we should see many
instructions all referring to the same (potentially complex) node.

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.
>

The IR is not a normalized representation already though. It's primary
consumer and producer are libraries and machines, not humans. Debug
metadata, TBAA metadata, and numerous other complexities are already
present.

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.
>

Yep, I'm just trying to explain my perspective on these issues. =]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120415/5bf2f8fe/attachment.html>