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. I’m still leaning towards having both an intrinsic and an instruction, and if they happen to have the same behavior then that’s fine. If fneg is to be a special instruction with extra promises (vs the other FP instructions) then this fact needs to be loudly present in the documentation. -- Kevin P. Neal SAS/C and SAS/C++ Compiler Host Research and Development SAS Institute, Inc. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Sanjay Patel via llvm-dev Sent: Wednesday, September 26, 2018 1:25 PM To: cameron.mcinally at nyu.edu Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [FPEnv] FNEG instruction To bring it back to the question of fneg, let me know if this is an accurate summary: 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?). 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). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180926/158a5513/attachment.html>
On Wed, Sep 26, 2018 at 2:14 PM Kevin Neal via llvm-dev < 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/1a33880c/attachment.html>
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>