-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[indvars] Allow widenWithVariantUse to succeed without extend users #71557
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 all commits
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 |
---|---|---|
|
@@ -34,11 +34,13 @@ define i16 @foo() { | |
; CHECK-NEXT: [[J_011:%.*]] = phi i16 [ 0, [[FOR_COND1_PREHEADER]] ], [ [[INC:%.*]], [[FOR_BODY4]] ] | ||
; CHECK-NEXT: [[SUM_110:%.*]] = phi i16 [ [[SUM_012]], [[FOR_COND1_PREHEADER]] ], [ [[ADD5]], [[FOR_BODY4]] ] | ||
; CHECK-NEXT: [[TMP2:%.*]] = add nuw nsw i32 [[INDVAR]], [[TMP0]] | ||
; CHECK-NEXT: [[TMP3:%.*]] = sext i16 [[J_011]] to i32 | ||
; CHECK-NEXT: [[TMP4:%.*]] = add nuw nsw i32 [[TMP3]], [[TMP0]] | ||
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 instructions look dead. Is that the fault of LoopFlatten or IndVars? 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. LoopFlatten. It doesn't call up after calling the widening routines. I added adce to at least one of the LoopFlatten test previously, can do so for this one as well. (They're already invoking multiple passes.) 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. I see, LoopFlatten ignores the DeadInsts parameter. It would be best to make it drop the dead insts directly instead of adding adce to tests. |
||
; CHECK-NEXT: [[ADD:%.*]] = add nuw nsw i16 [[J_011]], [[MUL]] | ||
; CHECK-NEXT: [[TMP3:%.*]] = trunc i32 [[TMP2]] to i16 | ||
; CHECK-NEXT: [[ARRAYIDX:%.*]] = getelementptr inbounds [64 x i16], ptr @v, i16 0, i16 [[TMP3]] | ||
; CHECK-NEXT: [[TMP4:%.*]] = load i16, ptr [[ARRAYIDX]], align 1 | ||
; CHECK-NEXT: [[ADD5]] = add nsw i16 [[TMP4]], [[SUM_110]] | ||
; CHECK-NEXT: [[TMP5:%.*]] = trunc i32 [[TMP2]] to i16 | ||
; CHECK-NEXT: [[ARRAYIDX:%.*]] = getelementptr inbounds [64 x i16], ptr @v, i16 0, i16 [[TMP5]] | ||
; CHECK-NEXT: [[TMP6:%.*]] = load i16, ptr [[ARRAYIDX]], align 1 | ||
; CHECK-NEXT: [[ADD5]] = add nsw i16 [[TMP6]], [[SUM_110]] | ||
; CHECK-NEXT: [[INDVAR_NEXT]] = add i32 [[INDVAR]], 1 | ||
; CHECK-NEXT: [[INC]] = add nuw nsw i16 [[J_011]], 1 | ||
; CHECK-NEXT: [[EXITCOND_NOT:%.*]] = icmp eq i32 [[INDVAR_NEXT]], 16 | ||
|
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 don't really get why this transform is correct. It looks like indvars.iv here is a normal {%start,+,-1} addrec, but then the exit condition here becomes
{%start+4294967295,+,-1} ugt 6
? That's not the same as{%start-1,+,-1} ugt 6
in a smaller bit width.Am I missing something here?
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.
The key fact is that we have a loop entry condition which proves both that start is non-negative, and that start -1 is still positive. Given this precondition trunc(zext(start)+4294967295) == start-1. Given we know we exit without the IV every becoming negative (in either 32 or 64), this should be the same.
In general, this transform relies on the high bits of the addrec being don't care except for the identified users it visits and proves that the result of the user is unchanged by the possible change in the high bits.
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.
Actually, hold on. You're right and there's something funky going on here. We have a 64 bit IV which enumerates the same values as the 32 bit IV, but then the actual comparison uses a 64 bit offset (without truncation), and the high bits change the exit condition.
I need to investigate this further, thanks for spotting.