Skip to content

[LV] Fix crash when building partial reductions using types that aren't known scale factors #136680

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.

Sign up for GitHub

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

Merged
merged 4 commits into from
Apr 23, 2025
Merged

[LV] Fix crash when building partial reductions using types that aren't known scale factors #136680

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
230b1e8
[loop-vectorize] Fix crash when using types that aren't known scale f…
NickGuy-Arm Apr 22, 2025
f213f98
Update test
NickGuy-Arm Apr 22, 2025
f33ed38
Update and move test
NickGuy-Arm Apr 22, 2025
2b0a8cb
Remove whitespace
NickGuy-Arm Apr 23, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 7 additions & 3 deletions llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8826,9 +8826,13 @@ bool VPRecipeBuilder::getScaledReductions(

PartialReductionChain Chain(RdxExitInstr, ExtA, ExtB, BinOp);

unsigned TargetScaleFactor =
PHI->getType()->getPrimitiveSizeInBits().getKnownScalarFactor(
A->getType()->getPrimitiveSizeInBits());
TypeSize PHISize = PHI->getType()->getPrimitiveSizeInBits();
TypeSize ASize = A->getType()->getPrimitiveSizeInBits();

if (!PHISize.hasKnownScalarFactor(ASize))
return false;

unsigned TargetScaleFactor = PHISize.getKnownScalarFactor(ASize);

if (LoopVectorizationPlanner::getDecisionAndClampRange(
[&](ElementCount VF) {
Expand Down
21 changes: 21 additions & 0 deletions llvm/test/Transforms/LoopVectorize/AArch64/partial-reduce-chained.ll
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1030,6 +1030,27 @@ for.body: ; preds = %for.body.preheader,
br i1 %exitcond.not, label %for.cond.cleanup, label %for.body, !loop !1
}


define i40 @chained_partial_reduce_not_known_factor(i32 %a, i32 %b, i32 %N) {
entry:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also have some check lines here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added, I also noticed that, since removing the no-op or, this is no longer necessarily a chained partial reduction. So I've moved the test and added a comment to illustrate more clearly what the purpose of the test is.

br label %for.body

for.body:
%red = phi i40 [ 0, %entry ], [ %1, %for.body ]
%iv = phi i16 [ 0, %entry ], [ %iv.next, %for.body ]
%resize = sext i32 %a to i40
%resize4 = sext i32 %b to i40
%0 = or i40 %resize4, %resize
%1 = or i40 %red, %0
%iv.next = add i16 %iv, 1
%cmp = icmp slt i16 %iv, 1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this also reproduce with more iterations? If so, would be good increase iterations to make things more robust in case we ever decide to bail out for low iteration loops early.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does indeed. I've made it use %N as it was otherwise unused.

br i1 %cmp, label %for.body, label %exit

exit:
%result.lcssa = phi i40 [ %1, %for.body ]
ret i40 %result.lcssa
}

attributes #0 = { vscale_range(1,16) }


Expand Down
Loading