The PPCISD::SExtVElems was added by commit https://reviews.llvm.org/D34009 However, we have another ISD node ISD::SIGN_EXTEND_INREG that perfectly match the semantics of SExtVElems. And the DAGCombiner has some combine rules for SIGN_EXTEND_INREG that produce better code.
Details
- Reviewers
nemanjai jsji hfinkel lkail - Group Reviewers
Restricted Project - Commits
- rGd0fb34dc0967: [PowerPC] Replace the PPCISD:: SExtVElems with ISD::SIGN_EXTEND_INREG to…
Diff Detail
Event Timeline
Can you provide tests to demonstrate how ISD::SIGN_EXTEND_INREG works on PowerPC? Also, from my view, this patch should not be a NFC patch, since we somehow change execution paths, though we finally get the same codegen.
Hmm, yes, not NFC as the dag combine rule will applied if with generic isd node. I will cook some tests.
Rebase the patch. And I think the test case added by https://reviews.llvm.org/D34009 already cover my patch. We are combing the instructions into sext_inreg instead of Power specific node SExtVElems, and then, it is selected as hw instruction which is defined in the pattern td.
Seems that the pre merge checker has problem in detecting the dependent patch landing or not. Remove the parent revision and trigger the check again.
We are combing the instructions into sext_inreg instead of Power specific node SExtVElems, and then, it is selected as hw instruction which is defined in the pattern td.
CMIIW, SExtVElems works on types that fit in a vector register, like v16i8. And according to codes SExtVElems generates, it intends to sext lower bits of target element type in-place, which suggests SIGN_EXTEND_INREG.
Yes, it is doing something like: a << N >> N; The SExtVElems has the same semantics with SIGN_EXTEND_INREG if its type is vector.
LGTM. Please wait a couple of days to land in case other reviewers have other concerns.