<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="gmail_quote">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).</div><div class="gmail_quote"><br></div><div class="gmail_quote">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 r<span style="font-size:13px">210467 (</span><span style="font-size:13px">which exposed nsw and nuw</span><span style="font-size:13px">) 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.</span></div><div class="gmail_quote"><br></div></div><div class="gmail_quote">On Tue, Jan 13, 2015 at 1:09 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span><br><div class="gmail_quote">On Mon, Jan 12, 2015 at 1:18 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>> Whatever happened to tracking the safe-or-fast-ness of FP math on<br>
> instructions? Is tracking this property at a function granularity<br>
> correct? I seem to recall nobody wanted to thread this through the<br>
> SDAG.<br>
<br>
</span>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.</blockquote></div><br></span>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...</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div></div>
<br>_______________________________________________<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></div>