[llvm-dev] [FPEnv] FNEG instruction

[Kevin Neal via llvm-dev]

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>