<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Wed, Sep 26, 2018 at 1:24 PM Sanjay Patel <<a href="mailto:spatel@rotateright.com" target="_blank">spatel@rotateright.com</a>> wrote:<br><div class="gmail_quote"><div>... </div><span class="gmail-im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>To bring it back to the question of fneg, let me know if this is an accurate summary: <br></div><div>1. fneg would be nice to have for clarity, but it doesn't make optimization in the default LLVM FP environment any easier/better. <br></div><div>2. We will have to do some preliminary work in the IR optimizer to avoid regressions if we add fneg to the IR.<br></div><div>3. We want fneg as a 1st class instruction even though the related fabs/copysign bitstring ops are intrinsics (because fneg is more common than the others?).<br></div><div>4. Adding fneg to IR means we do not need to add a constrained intrinsic for fneg (likewise, there's no need for constrained fabs/copysign because those intrinsics already exist).<br></div><div><br></div></div></div></div></div></blockquote><div><br></div></span></div></blockquote><div> </div><div>For simplicity's sake, I agree with all this. I could nit-pick a bit, but it's not productive to the FNEG conversation. </div><div><br></div><div>Thanks for summarizing, Sanjay.</div></div></div></div>