search for: isfneg

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

...maybe a naive question, but why not do similar shuffle canonicalizations on unary (or ternary) operations? That may be a better fix in the long run. > But glancing at Reassociate.cpp is scarier. It does a lot of stuff like > this: > if (BinaryOperator::isNeg(TheOp) || BinaryOperator::isFNeg(TheOp)) > X = BinaryOperator::getNegArgument(TheOp); > > I think that's going to fail without a (terrible) hack to treat the > proposed fneg as a binop. So that's probably a preliminary requirement: > find all uses of BinaryOperator::isFNeg() and update them to use m_FN...

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