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

[Eric Christopher]

Hi Akira,

On Thu Jan 08 2015 at 5:36:54 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
>
>
Thanks for coming back around to this. I'd hoped to have most of this
handled, but as you can tell it's a nice herd of yaks to get everything
playing nicely.


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

These two combined seems a little weird. Do you mean that you plan on,
effectively, changing the IR if someone passes a command line flag to an
existing set of 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).
>
>
Another thought is to put it as part of the feature string rather than
adding it as a separate attribute. That way you won't have to add a lookup
in each target.


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

This can be done first if you like at the moment, though you may run into
other problems and testing may be somewhat minimal.


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


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

This is an interesting solution, but involves changing IR files and I don't
know that we want to do this (as I mentioned above). But I do admit I like
it more than having to check both TargetOptions and the attribute to do it.

Another thing you haven't brought up is the inliner (or other cross
function optimizations)- what do you plan on doing there? Think two files,
one compiled with and one compiled without and linked together.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150112/513df75e/attachment.html>