Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
There's likely other combines that will also need to be updated but this is the most important one blocking D143767. I'd like to take a more holistic look at the others as part of work to unify some code paths. For example, I want to canonicalise sve intrinsic calls where the predicate is all active to use the "undef" intrinsics so that some code duplication within the code generator can be removed. With that said, please shout if you know of something critical that should be handled before D143767 lands.
llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp | ||
---|---|---|
1622–1625 | Is this case separate from instCombineSVEVectorAdd because the "undef" variant can't combine to fmla_u unless both the fmul and fadd are of the _u variants? Or because this case can't benefit from combines in instCombineSVEVectorBinOp? |
llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp | ||
---|---|---|
1622–1625 | The formerish. fadd_m(pg, a, fmul_u(pg, b, c)) expects the inactive elements to come from a, which fmla_u does not guarantee. It's worth pointing out the opposite is a valid transformation (i.e. fadd_u(pg, a, fmul_m(pg, b, c)) --> fmla_u(a, b, c) but that's new and I have half a thought it'll be better to soften the fmul_m to fmul_u rather than jumping straight to fmla_u. This does mean we're not getting the benefit of instCombineSVEVectorBinOp but here my plan is to rewrite m instrinsics that take an all active predicate to their equivalent u intrinsic, to minimise duplication. |
Is this case separate from instCombineSVEVectorAdd because the "undef" variant can't combine to fmla_u unless both the fmul and fadd are of the _u variants? Or because this case can't benefit from combines in instCombineSVEVectorBinOp?