[LLVMdev] Enable changing UnsafeFPMath on a per-function basis

[Akira Hatanaka]

We already sort of model fast math flags at per-function level by resetting
TargetOptions before selection dag is run. My proposal just makes changes
that are needed to parallelize the backend (sorry about the misleading
title of this thread).

If modeling the flags at per-instruction level is the right thing to do, I
agree that I shouldn't proceed with my current plan. I think exposing fp
flags in selection dag needs a little more work than r210467 (which exposed
nsw and nuw) did. In particular, some of the targets set operation actions
based on the value of TargetOptions::UnsafeFPMath (see
X86TargetLowering::resetOperationActions), which means legalization has to
examine the flags in addition to the opcode and type to get the operation
action.

On Tue, Jan 13, 2015 at 1:09 PM, Chandler Carruth <chandlerc at google.com>
wrote:

>
> On Mon, Jan 12, 2015 at 1:18 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>
>> > Whatever happened to tracking the safe-or-fast-ness of FP math on
>> > instructions? Is tracking this property at a function granularity
>> > correct? I seem to recall nobody wanted to thread this through the
>> > SDAG.
>>
>> No, I think we did want to do that, just no one has yet done it. We now
>> have NSW/NUW in SDAG, so it should not be too much different for the FP
>> flags.
>
>
> FWIW, I think it is a mistake to pursue the per-function modeling of this
> given how close we are to having proper per-instruction tracking of this. I
> would much rather see work going toward that if we think that is the right
> long-term thing for LLVM...
>
> If this is super simple to do for per-function granularity, cool. But if
> it is adding lots of complexity (which I'm worried about with Chris B's
> comments below) I think it makes more sense to focus on doing per-DAG-node
> fast math flags.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150114/0cec3f2d/attachment.html>