Which exactly was the plan? Add a new, regular instruction? Add a new constrained math intrinsic? Both? Andrew Kaylor made a good point here: * As I said, all LLVM IR FP instructions are //assumed// to have no side effects. I'm not sure we want an instruction that goes beyond this to be //defined// as having no side effects. It adds a complication to the language and introduces restrictions on the code generator that aren't needed in the ordinary case of non-constrained FP. The target code generators are free to do anything they want with the other FP instructions, including things that introduce new FP status flags being set that otherwise wouldn't be, and for the normal case the back ends should be free to do that with fneg as well. Personally, I’m not sure I like the idea of having exceptions to the rule that FP instructions also have constrained versions. So I lean towards having both a regular FNEG and a constrained version. But I think I remember pushback. I can’t put my fingers on the message, though. -- Kevin P. Neal SAS/C and SAS/C++ Compiler Host Research and Development SAS Institute, Inc. From: xkrebstarx <xkrebstarx at gmail.com> Sent: Tuesday, September 11, 2018 2:29 PM To: Cameron Jordan McInally <cameron.mcinally at nyu.edu> Cc: t.p.northover at gmail.com; llvm-dev at lists.llvm.org; ulrich.weigand at de.ibm.com; Kevin Neal <Kevin.Neal at sas.com> Subject: Re: [llvm-dev] [FPEnv] FNEG instruction EXTERNAL Ping... I'd like to hear from the major stakeholders on whether we can proceed with this change or not. Either way, it would be nice to pass this road block. If anyone watching is in close proximity to those that can approve such a change, I would appreciate it if you would tap them on the shoulder for me. Thanks again, Cameron On Thu, Aug 30, 2018 at 11:38 AM Cameron McInally via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: On Thu, Aug 30, 2018 at 11:14 AM, Tim Northover <t.p.northover at gmail.com<mailto:t.p.northover at gmail.com>> wrote: ... I don't think it matters for the question at hand, but I tested AArch64 too and it exhibits the behaviour you were describing. That is, we'd have problems if an fsub -0.0 was actually CodeGened like that (it's not, of course). Great data point. So it's not just a theoretical problem. Thanks, Tim! _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180911/9e470ab8/attachment.html>
On Tue, Sep 11, 2018 at 2:45 PM, Kevin Neal via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Which exactly was the plan? > > > > Add a new, regular instruction? > > > > Add a new constrained math intrinsic? > > > > Both? > > >I'd like to add an explicit FNEG IR operator. We would not need a constrained FNEG operator if we go this route.> Andrew Kaylor made a good point here: > > - As I said, all LLVM IR FP instructions are //assumed// to have no > side effects. I'm not sure we want an instruction that goes beyond this to > be //defined// as having no side effects. It adds a complication to the > language and introduces restrictions on the code generator that aren't > needed in the ordinary case of non-constrained FP. The target code > generators are free to do anything they want with the other FP > instructions, including things that introduce new FP status flags being set > that otherwise wouldn't be, and for the normal case the back ends should be > free to do that with fneg as well. > > > > Personally, I’m not sure I like the idea of having exceptions to the rule > that FP instructions also have constrained versions. So I lean towards > having both a regular FNEG and a constrained version. > > > > But I think I remember pushback. I can’t put my fingers on the message, > though. >We touched on this in the Differential Review and on this thread. To summarize: FNEG(X) is not really the same operation as FSUB(-0.0, X), although the differences are admittedly subtle. I even went as far to say that any xforms between the two operations should only occur under FastMath conditions. If we follow those rules, I think emergence guarantees that we don't have to worry about the side effects of FNEG (please correct me if I've missed something). Extending on that, I suspect that we should not be canonicalizing FNEG(X) as FSUB(-0.0, X), but rather as XOR(X, 1 << (SIZE_OF_TYPE_IN_BITS - 1)). A utility function could provide us with the sign-bit constant, so it's not that ugly. That said, I agree that Andrew's take is compelling. And I would be okay with adding a constrained FNEG to solve the immediate issue, if that is the final decision. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180911/dba24998/attachment.html>
+1 for an explicit FNEG instruction, since as previously discussed, it has stricter requirements for what value may be returned by the operation. And strengthening the requirement on FSUB is not feasible when the values are variables rather than literals. That is: FSUB(-0.0, NaN) = either NaN *or* -NaN FSUB(-0.0, -NaN) = either NaN *or* -NaN FNEG(NaN) = -NaN FNEG(-NaN) = NaN On Tue, Sep 11, 2018 at 3:35 PM Cameron McInally via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Tue, Sep 11, 2018 at 2:45 PM, Kevin Neal via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Which exactly was the plan? >> >> >> >> Add a new, regular instruction? >> >> >> >> Add a new constrained math intrinsic? >> >> >> >> Both? >> >> >> > > I'd like to add an explicit FNEG IR operator. We would not need a > constrained FNEG operator if we go this route. > > >> Andrew Kaylor made a good point here: >> >> - As I said, all LLVM IR FP instructions are //assumed// to have no >> side effects. I'm not sure we want an instruction that goes beyond this to >> be //defined// as having no side effects. It adds a complication to the >> language and introduces restrictions on the code generator that aren't >> needed in the ordinary case of non-constrained FP. The target code >> generators are free to do anything they want with the other FP >> instructions, including things that introduce new FP status flags being set >> that otherwise wouldn't be, and for the normal case the back ends should be >> free to do that with fneg as well. >> >> >> >> Personally, I’m not sure I like the idea of having exceptions to the rule >> that FP instructions also have constrained versions. So I lean towards >> having both a regular FNEG and a constrained version. >> >> >> >> But I think I remember pushback. I can’t put my fingers on the message, >> though. >> > > We touched on this in the Differential Review and on this thread. To > summarize: > > FNEG(X) is not really the same operation as FSUB(-0.0, X), although the > differences are admittedly subtle. I even went as far to say that any > xforms between the two operations should only occur under FastMath > conditions. If we follow those rules, I think emergence guarantees that we > don't have to worry about the side effects of FNEG (please correct me if > I've missed something). > > Extending on that, I suspect that we should not be canonicalizing FNEG(X) > as FSUB(-0.0, X), but rather as XOR(X, 1 << (SIZE_OF_TYPE_IN_BITS - 1)). A > utility function could provide us with the sign-bit constant, so it's not > that ugly. > > That said, I agree that Andrew's take is compelling. And I would be okay > with adding a constrained FNEG to solve the immediate issue, if that is the > final decision. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180911/2d92395f/attachment.html>