<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 6, 2016 at 5:02 PM, Mehdi AMINI <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">joker.eph added a subscriber: joker.eph.<br>
joker.eph added a comment.<br>
<br>
I wonder about the design of this, especially since Chris (and Chandler) rejected it in the past: <a href="http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20121217/159446.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20121217/159446.html</a> ?<br>
<div><div><br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="http://reviews.llvm.org/D14707" rel="noreferrer" target="_blank">http://reviews.llvm.org/D14707</a><br>
<br></div></div></blockquote><div><br></div><div>Thanks, Mehdi. I wasn't aware of that discussion; cc'ing those folks and llvm-dev.<br></div><div><br></div><div>The earlier proposal distinguished between intrinsics and regular calls, while this does not. This adds FMF to all calls that are FPMathOperators (return FP or FP vector). I don't know if that makes it more or less objectionable than the previous proposal.<br><br></div><div>Note the earlier suggestions/comments in the Phab review:<br></div><div>We could slide FMF into call instruction attributes, but I thought that was worse given that FMF continues to evolve ( <a href="http://reviews.llvm.org/D14067" target="_blank">http://reviews.llvm.org/D14067</a> ).<br><br></div><div>There are a handful of places in LibCallSimplifier where we can use FMF on calls today (and I already changed a few of those in recent commits). That number will grow over time as we add more optimizations. In theory, we could also use FMF on calls for DAG optimizations if we extend that too. <br><br>The main motivation for putting FMF on a call rather than relying on a function-level attribute is the LTO case. There are also (insane?) customers that want to specify relaxed/strict math at whatever granularity we will allow via pragma in C source code. I think these are the same motivations that drove FMF for IR FP math instructions in the first place. This patch get us closer to the goal of mixed fast/strict math in LLVM. If there's a better way to implement this, I'll try to help make it happen.<br></div></div><br></div></div>