-
Notifications
You must be signed in to change notification settings - Fork 14.4k
[VPlan] Support VPWidenIntOrFpInductionRecipes with EVL tail folding #144666
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 6 commits
cab6f07
4e15c3f
45a6d99
b3c55e2
fcb8bb7
0037eb2
45ba6fc
153da21
f1c507e
ac8d637
f63e783
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -156,7 +156,8 @@ bool VPlanVerifier::verifyEVLRecipe(const VPInstruction &EVL) const { | |
.Case<VPWidenIntrinsicRecipe>([&](const VPWidenIntrinsicRecipe *S) { | ||
return VerifyEVLUse(*S, S->getNumOperands() - 1); | ||
}) | ||
.Case<VPWidenStoreEVLRecipe, VPReductionEVLRecipe>( | ||
.Case<VPWidenStoreEVLRecipe, VPReductionEVLRecipe, | ||
VPWidenIntOrFpInductionRecipe>( | ||
[&](const VPRecipeBase *S) { return VerifyEVLUse(*S, 2); }) | ||
.Case<VPWidenLoadEVLRecipe, VPVectorEndPointerRecipe>( | ||
[&](const VPRecipeBase *R) { return VerifyEVLUse(*R, 1); }) | ||
|
@@ -165,18 +166,30 @@ bool VPlanVerifier::verifyEVLRecipe(const VPInstruction &EVL) const { | |
.Case<VPInstruction>([&](const VPInstruction *I) { | ||
if (I->getOpcode() == Instruction::PHI) | ||
return VerifyEVLUse(*I, 1); | ||
if (I->getOpcode() != Instruction::Add) { | ||
errs() << "EVL is used as an operand in non-VPInstruction::Add\n"; | ||
switch (I->getOpcode()) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What purpose does this switch serve? It seems to be the same functionally as the prior if-clause? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Previously any user of EVL that wasn't an add was an error. This switch statement relaxes it to also allow UIToFP/Trunc/ZExt/Mul/FMul when VerifyLate is true, i.e. after the VPWidenIntOrFpInductionRecipe is expanded. The changes to the comments below are to reflect the fact that it we allow no longer just adds. I'm also in half a mind here that we should just skip verifying EVL uses when VerifyLate is true, I think we'll need to add more cases for VPWidenPointerInductionRecipe later. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, the VerifyLate flag here is what confused me. I see it now. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Might be worth adding a brief comment below about why this is only check depending on VerifyLate. |
||
case Instruction::Add: | ||
break; | ||
case Instruction::UIToFP: | ||
case Instruction::Trunc: | ||
case Instruction::ZExt: | ||
case Instruction::Mul: | ||
case Instruction::FMul: | ||
if (!VerifyLate) { | ||
errs() << "EVL used by unexpected VPInstruction\n"; | ||
return false; | ||
} | ||
lukel97 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
break; | ||
default: | ||
errs() << "EVL used by unexpected VPInstruction\n"; | ||
return false; | ||
} | ||
if (I->getNumUsers() != 1) { | ||
errs() << "EVL is used in VPInstruction:Add with multiple " | ||
"users\n"; | ||
errs() << "EVL is used in VPInstruction with multiple users\n"; | ||
return false; | ||
} | ||
if (!VerifyLate && !isa<VPEVLBasedIVPHIRecipe>(*I->users().begin())) { | ||
errs() << "Result of VPInstruction::Add with EVL operand is " | ||
"not used by VPEVLBasedIVPHIRecipe\n"; | ||
errs() << "Result of VPInstruction with EVL operand is not used by " | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. These changes seem unneeded? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep, this can probably stay as-is, because only VPInstruction::Add is possible at this point? |
||
"VPEVLBasedIVPHIRecipe\n"; | ||
return false; | ||
} | ||
return true; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
independent: Could we assert there that there are no other unsuspported users of VF, as that would indicate a mis-compile? (e.g. if new recipes which use VF get added)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so, but it looks like VPScalarIVStepsRecipe currently has the VF as an operand. Although it's only used when unrolled which we don't allow for EVL tail folding so I don't think it's a miscompile currently.
I can handle this in a separate PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in #146339