search for: maxrecurse

...> gets us a long way. But we'd also need to update IR passes in places > where the Opcode is explicitly checked. E.g.: > > ``` > switch (Opcode) { > <snipped> > 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,...

...ern matcher to recognize intrinsics gets us a long way. But we'd also need to update IR passes in places where the Opcode is explicitly checked. E.g.: ``` switch (Opcode) { <snipped> 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...

...> gets us a long way. But we'd also need to update IR passes in places > where the Opcode is explicitly checked. E.g.: > > ``` > switch (Opcode) { > <snipped> > 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(...

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