llvm dev - Jan 2015 - [LLVMdev] Enable changing UnsafeFPMath on a per-function basis

----- Original Message -----
> From: "Reid Kleckner" <rnk at google.com>
> To: "Akira Hatanaka" <ahatanak at gmail.com>
> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Sent: Monday, January 12, 2015 2:54:48 PM
> Subject: Re: [LLVMdev] Enable changing UnsafeFPMath on a per-function basis
> 
> 
> 
> 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.

 -Hal
> 
> 
> If we agree that we want to track this at the function level, then
> your proposal seems reasonable.
> 
> 
> 
> 
> 
> 
> 
> On Thu, Jan 8, 2015 at 5:36 PM, Akira Hatanaka < ahatanak at gmail.com
>
> wrote:
> 
> 
> 
> 
> To continue the discussion I started last year (see the link below)
> on embedding command-line options in bitcode, I came up with a plan
> to improve the way the backend changes UnsafeFPMath on a
> per-function basis. The code in trunk currently resets
> TargetOptions::UnsafeFPMath at the beginning of
> SelectionDAGISel::runOnMachineFunction to enable compiling one
> function with “unsafe-fp-math=true” and another with
> “unsafe-fp-math=false”, but this won’t work if we want to
> parallelize the backend in the future, which is something Eric
> mentioned in his talk last year.
> 
> 
> Here is the link to the original discussion I started last year:
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-November/078785.html
> 
> 
> 
> These are the changes I plan to make:
> 
> 
> 
> 1. In llc.cpp (and any other tools that use the option), change the
> function attribute in the IR based on the value of command line
> option “enable-unsafe-pf-math” (EnableUnsafeFPMath, defined in
> CommandFlags.h).
> 
> 2. Replace usages of TargetOptions::UnsafeFPMath with calls to a
> function which gets the value of attribute “unsafe-fp-math” in the
> IR.
> 
> 3. Stringify function attribute “unsafe-fp-math” and append it to the
> string that is used as the lookup key in
> TargetMachine::getSubtargetImpl(const Function&). Also, pass the
> function attribute to the subtarget constructors that need it to
> construct itself (e.g., ARM) or construct one of the backend objects
> (e.g., X86, which needs it in the constructor of X86TargetLowering).
> 
> 4. In MachineFunction’s constructor, call
> TargetMachine::getSubtargetImpl(const Function &) to initialize STI
> (pointer to the per-function subtarget object). Currently, the
> version of TargetMachine::getSubtargetImpl that doesn’t take a const
> Function& parameter is called, which returns the module-level
> subtarget object.
> 
> 5. Fix ARMAsmPrinter::emitAttributes to compute the value of
> TargetOptions::UnsafeFPMath based on the function attributes of all
> the functions in the module being compiled (see the link below).
> 
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-December/079904.html
> 
> 
> 6. Move the code in CGCall.cpp that sets the function attributes to
> BackendUtil.cpp. clang should set the function attributes regardless
> of whether it is compiling from source code or from an IR file
> (e.g., clang foo1.ll -o foo1.s -ffast-math), but currently this
> happens only if it’s compiling from source.
> 
> Any comments and suggestions are welcome. If we can agree on the main
> issues, I'll follow up with patches that implement the changes I
> proposed.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150113/0795cad6/attachment.html>

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>