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? From: Cameron McInally <cameron.mcinally at nyu.edu> Sent: Wednesday, September 26, 2018 2:30 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:14 PM Kevin Neal via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Do we really want to have fneg be the only instruction with guaranteed no side effects? That just sounds like a gotcha waiting to happen. Or it could result in horrible code depending on the architecture. That's not quite right. FNEG(X) and FSUB(-0.0, X) are not the same operation. They are *very* similar, but still different at an edge case(s). The current transformations that occur in LLVM are unsafe. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180926/0e96dd1f/attachment.html>
On Wed, Sep 26, 2018 at 2:47 PM Kevin Neal <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/78705565/attachment.html>
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>