<div dir="ltr">On Tue, Jun 2, 2015 at 3:40 PM, Akira Hatanaka <span dir="ltr"><<a href="mailto:ahatanak@gmail.com" target="_blank">ahatanak@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Tue, Jun 2, 2015 at 1:52 PM, Sanjay Patel <span dir="ltr"><<a href="mailto:spatel@rotateright.com" target="_blank">spatel@rotateright.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"><div dir="ltr"><div><div><div>Hi Akira,<br><br></div>To be honest, I wasn't sure how this all works. Any advice or help is much appreciated. :)<br></div><br>I modeled the changes for this patch on the existing FPOpFusion::FPOpFusionMode code. Does that have a corresponding function attribute? If not, how does that work for an LTO build for example?<br><br></div></div></blockquote><div><br></div></span><div>As far as I can tell, FPOpFusionMode doesn't have a corresponding function attribute, so it won't work for LTO builds.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div>Ideally, I think that both of these would become part of the fast-math-flags that I'm trying to extend to the DAG, but a function attribute should probably be an intermediate step?<br><div><br></div></div><div><div><div class="gmail_extra"><br></div></div></div></blockquote><div><br></div></span><div>Yes, ideally it should be a DAG node flag. Is the undefined behavior discovered when r236546 was committed still blocking progress on that work?</div></div></div></div></blockquote><div><br></div><div>I scaled the r236546 patch back to only affect binary nodes in:<br><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_rL237046&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=lnwHeUR2zQH96JDh9kfdhhUvup_Q6-Qrsqw6wtkHPeY&s=NLYNmawel5cokWnMqkrfmTdu0juxNWOLrOiBhUNuJoE&e=">http://reviews.llvm.org/rL237046</a><br><br></div><div>But this patch exposed another bug that I'm hoping to get fixed with:<br><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D9893&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=lnwHeUR2zQH96JDh9kfdhhUvup_Q6-Qrsqw6wtkHPeY&s=8OnYUa2hI5N-4yj72aWDYh-M9-XIjpVOI1CTQ13mACI&e=">http://reviews.llvm.org/D9893</a><br><br></div><div>Unfortunately, I suspect there will be more bugs like that. They only become visible after FMF is added. In the commit thread for r237046, Nick Lewycky suggested that I should resubmit the FMF patch under an experimental enablement flag so it could be tested further before being made default. I will get that submitted again soon.<br></div><div><br></div></div><br></div></div>