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

Hal Finkel hfinkel at anl.gov
Mon Jan 12 13:18:27 PST 2015


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




More information about the llvm-dev mailing list