I have no example side effects in hand. But LLVM targets a bunch of architectures, and who knows what the future holds. So it may be prudent to not promise too much so as to leave ourselves an escape hatch. Doesn’t LLVM target some chips that have floating point instruction sets that are not IEEE compliant? Can we be certain that no new LLVM target will ever have to jump through hoops to avoid side effects simply because we promised that fneg would never, ever have any side effects? Assuming we do promise no side effects from fneg, ever and forever, then the documentation should say that clearly. From: Cameron McInally <cameron.mcinally at nyu.edu> Sent: Wednesday, September 26, 2018 3:03 PM To: Kevin Neal <Kevin.Neal at sas.com> Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [FPEnv] FNEG instruction EXTERNAL On Wed, Sep 26, 2018 at 2:47 PM Kevin Neal <Kevin.Neal at sas.com<mailto:Kevin.Neal at sas.com>> wrote: Well, yes, they are different operations. And, yes, this needs to be corrected. This wasn’t my point. It’s a given. I was getting at the _declared_ absence of side effects and what promises we make to anyone using the new fneg instruction. Is this a promise we want to make? What are the side effects that you're thinking about? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180926/3bcec223/attachment.html>
On Wed, Sep 26, 2018 at 3:36 PM Kevin Neal <Kevin.Neal at sas.com> wrote:> I have no example side effects in hand. But LLVM targets a bunch of > architectures, and who knows what the future holds. So it may be prudent to > not promise too much so as to leave ourselves an escape hatch. > > > > Doesn’t LLVM target some chips that have floating point instruction sets > that are not IEEE compliant? Can we be certain that no new LLVM target will > ever have to jump through hoops to avoid side effects simply because we > promised that fneg would never, ever have any side effects? > > > > Assuming we do promise no side effects from fneg, ever and forever, then > the documentation should say that clearly. >Maybe I'm misunderstanding the LangRef copy, but the promise of 'no side effects' is really saying that trapping behavior is not guaranteed to be preserved under optimizations. FNEG(X) never has side effects (it never traps). It is a bitwise operation. Now changing FNEG(X) into FSUB(-0.0, X) is a different conversation. Those two operations do not give bitwise identical results for all inputs. So, it's really not safe to replace one with the other [well, arguably only FNEG(X) --> FSUB(-0.0, X) isn't safe]. So, as long as we don't make an unsafe transformation, which can set incorrect bits if we do make it, then I don't foresee a problem with side-effects on FNEG. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180926/0190a7cb/attachment.html>
Regarding non-IEEE targets: yes, we definitely support those, so we do have to be careful about not breaking them. I know because I have broken them. :) See the discussion and related links here: https://reviews.llvm.org/D19391 But having an exactly specified fneg op makes that easier, not harder, as I see it. Unfortunately, if a target doesn't support this op (always toggle the sign bit and only the sign bit), then we can't canonicalize 'fsub -0.0, X' to 'fneg X' because those are not identical ops (denorms, NaN). So that leads back to the m_FNeg abstraction - it will have to match both ops to not lose optimizations. On Wed, Sep 26, 2018 at 2:04 PM Cameron McInally via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Wed, Sep 26, 2018 at 3:36 PM Kevin Neal <Kevin.Neal at sas.com> wrote: > >> I have no example side effects in hand. But LLVM targets a bunch of >> architectures, and who knows what the future holds. So it may be prudent to >> not promise too much so as to leave ourselves an escape hatch. >> >> >> >> Doesn’t LLVM target some chips that have floating point instruction sets >> that are not IEEE compliant? Can we be certain that no new LLVM target will >> ever have to jump through hoops to avoid side effects simply because we >> promised that fneg would never, ever have any side effects? >> >> >> >> Assuming we do promise no side effects from fneg, ever and forever, then >> the documentation should say that clearly. >> > > Maybe I'm misunderstanding the LangRef copy, but the promise of 'no side > effects' is really saying that trapping behavior is not guaranteed to be > preserved under optimizations. FNEG(X) never has side effects (it never > traps). It is a bitwise operation. > > Now changing FNEG(X) into FSUB(-0.0, X) is a different conversation. Those > two operations do not give bitwise identical results for all inputs. So, > it's really not safe to replace one with the other [well, arguably only > FNEG(X) --> FSUB(-0.0, X) isn't safe]. So, as long as we don't make an > unsafe transformation, which can set incorrect bits if we do make it, then > I don't foresee a problem with side-effects on FNEG. > _______________________________________________ > 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/20180927/409b7ede/attachment.html>