search for: m_fneg

...passes. > Implementation details. ¯\_(ツ)_/¯ Seriously though, this is interesting and something that I had not considered. Thinking aloud, what if we caught the FNEG pattern in the CreateFSub*(...) IRBuilder functions and generated an FNeg instruction instead? That way we could get rid of the m_FNeg(...) calls altogether. They would just be replaced with something like: (I.getOpcode() == Instruction::FNeg). Any transform that currently uses m_FNeg(...) would fail to build without an update. But maybe I'm not considering some substitution that could modify an FSub instruction in place??...

...)_/¯ >> >> Seriously though, this is interesting and something that I had not >> considered. Thinking aloud, what if we caught the FNEG pattern in >> the CreateFSub*(...) IRBuilder functions and generated an FNeg instruction >> instead? That way we could get rid of the m_FNeg(...) calls altogether. >> They would just be replaced with something like: (I.getOpcode() == >> Instruction::FNeg). Any transform that currently uses m_FNeg(...) would >> fail to build without an update. >> > > We don't want to get rid of the m_FNeg calls. Those ar...

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

...*HERE*** > return SimplifyFAddInst(LHS, RHS, FastMathFlags(), Q, MaxRecurse); > ``` > > And when a transformation succeeds, we'd need to update how the result > is returned. E.g.: > > ``` > // (-X) + Y --> Y - X > Value *X, *Y; > if (match(&I, m_c_FAdd(m_FNeg(m_Value(X)), m_Value(Y)))) > return BinaryOperator::CreateFSubFMF(Y, X, &I); <== ***HERE*** > ``` > > Both of those come for free with a complex type, along with the > pattern matching code. > > > Thanks for expanding on this! I think for InstructionSimplify it sho...

...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. >> > > I like this idea. > > So how do we get official approval to begin this work? > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/piper...

+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) = either NaN *or* -NaN FNEG(NaN) = -NaN FNEG(-NaN) = NaN On Tue, Sep 11,

...pped> case Instruction::FAdd: <== ***HERE*** return SimplifyFAddInst(LHS, RHS, FastMathFlags(), Q, MaxRecurse); ``` And when a transformation succeeds, we'd need to update how the result is returned. E.g.: ``` // (-X) + Y --> Y - X Value *X, *Y; if (match(&I, m_c_FAdd(m_FNeg(m_Value(X)), m_Value(Y)))) return BinaryOperator::CreateFSubFMF(Y, X, &I); <== ***HERE*** ``` Both of those come for free with a complex type, along with the pattern matching code. I'm not opposed to finding solutions for these problems, but this pitch has been around for a while n...

...ERE*** > return SimplifyFAddInst(LHS, RHS, FastMathFlags(), Q, MaxRecurse); > ``` > > And when a transformation succeeds, we'd need to update how the result > is returned. E.g.: > > ``` > // (-X) + Y --> Y - X > Value *X, *Y; > if (match(&I, m_c_FAdd(m_FNeg(m_Value(X)), m_Value(Y)))) > return BinaryOperator::CreateFSubFMF(Y, X, &I); <== ***HERE*** > ``` > > Both of those come for free with a complex type, along with the > pattern matching code. > Thanks for expanding on this! I think for InstructionSimplify it should be...

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

All: There will be a BoF talk at the EuroLLVM conference regarding Numerics (FMF and module flags which control fp behavior and optimization). Even if you are not going to be in attendance, please reply to this thread as we are collecting open issues and ideas for future direction in all layers of LLVM for which optimizations are controlled by numerics flags. Please read over the numerics blog

On Thu, Nov 12, 2020 at 12:03 PM Florian Hahn via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > There’s growing interest among our users to make better use of dedicated hardware instructions for complex math and I would like to re-start the discussion on the topic. Given that this original thread was started a while ago apologies if I missed anything already discussed