<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Basically my plan is to change the backend to use the value of "unsafe-fp-math" that is recorded in the IR as a function attribute instead of reading the value from TargetOptions::UnsafeFPMath (which is global). It doesn't change at which level (function or instruction level) fast FP math is tracked or make it harder to change selection sag to track it at a finer granularity, if someone decides to do that later.</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Mon, Jan 12, 2015 at 12:54 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>If we agree that we want to track this at the function level, then your proposal seems reasonable.<br><div><div><div><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Jan 8, 2015 at 5:36 PM, Akira Hatanaka <span dir="ltr"><<a href="mailto:ahatanak@gmail.com" target="_blank">ahatanak@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div>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.</div><div><br></div><div>Here is the link to the original discussion I started last year:</div><div><a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-November/078785.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-November/078785.html</a><br></div><div><br></div><div>These are the changes I plan to make:<br></div><div><p>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).</p><p>2. Replace usages of TargetOptions::UnsafeFPMath with calls to a function which gets the value of attribute “unsafe-fp-math” in the IR.</p><p>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).</p><p>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.</p><p>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).</p><p><a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-December/079904.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-December/079904.html</a><br></p><p>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.</p><p>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.</p></div></div>
<br></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></div>