search for: fneg

+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)...

On Tue, Sep 25, 2018 at 1:39 PM Sanjay Patel <spatel at rotateright.com> wrote: > I have 1 concern about adding an explicit fneg op to IR: > > Currently, fneg qualifies as a binop in IR (since there's no other way to > represent it), and we have IR transforms that are based on matching that > pattern (m_BinOp). With a proper unary fneg instruction, those transforms > are not going to fire anymore. So I thi...

...ay be a better fix in the long run. >> > > AFAIK, all of the math/logic folding that we do currently is on binary > operators because all of the instructions have that form: > http://llvm.org/docs/LangRef.html#instruction-reference > > As discussed, we fake the unary neg/not/fneg as binops. Excluding > control-flow, the only unary instructions are casts, and I don't see any > ternary or higher math ops other than intrinsics. > Digressing a bit... That sounds like a bug, not a feature. Casts/converts, rounds, abs, other libm functions, fmas, compares, and prob...

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 tha...

...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....

...n 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...

...om> wrote: > > > On Tue, Sep 25, 2018 at 2:28 PM Cameron McInally <cameron.mcinally at nyu.edu> > wrote: > >> On Tue, Sep 25, 2018 at 1:39 PM Sanjay Patel <spatel at rotateright.com> >> wrote: >> >>> I have 1 concern about adding an explicit fneg op to IR: >>> >>> Currently, fneg qualifies as a binop in IR (since there's no other way >>> to represent it), and we have IR transforms that are based on matching that >>> pattern (m_BinOp). With a proper unary fneg instruction, those transforms >>>...

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...

On Wed, 29 Aug 2018 at 07:51, Cameron McInally via llvm-dev <llvm-dev at lists.llvm.org> wrote: > The current thinking is that FNEG(X) and FSUB(-0.0, X) are not the same operation when X is a NaN or 0. Do you mean denormals (when flushed) rather than 0 there? AFAIK it's OK for 0 itself. > So, the xforms in question should only be valid under Fast-Math conditions. We could probably also "fix" the issue by tak...

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] FN...

I don't see any controversy for the preliminary requirement of removing BinaryOperator::isFNeg() and friends, so start with that? That work may reveal other potential regressions that we can patch in advance too. Other than that, I think there's really only a question of do we want 1 or both of fneg and fneg_constrained (and if we choose both, then I assume we'd also add fabs_constr...

Hey llvm-dev, Continuing a discussion from D50913... A group working on the FP rounding mode and trap-safety project have run into a situation where it would make sense to add a new FNEG instruction and decouple the existing FNEG<->FSUB transformations. The IEEE-754 Standard (Section 5.5.1) makes it clear that neg(x) and sub(-0.0,x) are two different operations. The former is a bitwise operation, while the latter is an arithmetic operation. That said, LLVM currently conflat...

...+000, %x ; <float> [#uses=1] store float %neg, float addrspace(11)* %result ret void } However, when I attempt to run it through my backend which can handle binary math ops correctly I keep asserting on the following item. Cannot yet select: 017B8010: i32 = fneg 017B7E78 What I cannot figure out is why it is attempting to pattern match on an i32 when there are no i32's in my test program. I've tried a custom lowering function that lowers it to dst = sub 0, src0 and forcing it to f32, but it complains that result and the op value types are inco...

...> [#uses=1] > store float %neg, float addrspace(11)* %result > ret void > } > > However, when I attempt to run it through my backend which can handle binary > math ops correctly I keep asserting on the following item. > > Cannot yet select: 017B8010: i32 = fneg 017B7E78 That seems strange... you definitely shouldn't be seeing an fneg with an i32 result. What sorts of changes have you made to the SPARC backend? Have you tried looking at the output of "llc -view-dag-combine1-dags" and "llc -view-legalize-dags" to see where exactly...

-----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Wednesday, September 10, 2008 3:30 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Custom Lowering and fneg On Wed, Sep 10, 2008 at 2:35 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Generating the following LLVM IR: > > define void @test_unary_op_anegate(float %x, float addrspace(11)* %result) > nounwind { > entry: > %neg = sub float -0.000000e+000, %x...

...ger return value. IR code just for reference: -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah Sent: Wednesday, September 10, 2008 4:20 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Custom Lowering and fneg -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Wednesday, September 10, 2008 3:30 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Custom Lowering and fneg On Wed, Sep 10, 2008 at 2:35 PM, Villmow...

...ting point instruction into an integer return value. Hmm, that's kind of strange... in that case, there's very little space for it to get messed up. Could you try setting a breakpoint in "llvm::SelectionDAG::getNode(unsigned Opcode, MVT VT, SDValue Operand)" and seeing where the fneg in question is built? -Eli

FYI, I was looking at the SSE/AVX codegen here: http://llvm.org/bugs/show_bug.cgi?id=20578 If LLVM starts caring about FP exceptions, even this won't be possible. Is there a way of doing an IEEE-754 fneg in C/C++? Ie, there's no fneg() in libm, so any C method we choose could cause an exception, and that's not allowed by the IEEE definition of fneg. On Fri, Aug 8, 2014 at 12:29 PM, Stephen Canon <scanon at apple.com> wrote: > > > On Aug 8, 2014, at 11:22 AM, David Jones &l...

...ncodings. copy(x) copies a floating-point operand x to a destination in the same format, with no change to the sign bit. negate(x) copies a floating-point operand x to a destination in the same format, reversing the sign bit. negate(x) is not the same as subtraction(0, x) (see 6.3). Note the MAY. fneg is required to flip the top bit even if the input is a NaN. But fneg is not required to maintain the other bits. If the input is a non-canonical NaN, the fneg MAY canonicalize it. In fact, even the ‘copy’ MAY canonicalize it. (it also MAY choose to not canonicalize it) Thus, if the integer being f...

...nstrained FP intrinsics for operations that have side effects (i.e. can trap). The quiet-computational sign-bit operations are special. They never have side effects (i.e. never trap). We have not been able to find a bad transformation for those (i.e. a xform to a trapping operation) other than the FNEG(X) --> FSUB(-0.0, X) transform. If you can find a transform from one of the quiet-computational operations to a trapping operation, then we should discuss that. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachmen...