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

Akira Hatanaka ahatanak at gmail.com
Thu Jan 8 17:36:54 PST 2015


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


More information about the llvm-dev mailing list