| Issue |
129554
|
| Summary |
Clarification: EPResumeVal && "must have a resume value for the canonical IV" assert vs downstream changes
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
t-larina
|
I work at Qualcomm, and I am finding this [patch](https://github.com/llvm/llvm-project/commit/0e70289f373d40f3f8a4cc5c35dd02bfe909ca83) conflicts with some of our downstream changes. We're generating an IR with two PHIs in a basic block when optimizing this simple source [loop_i.txt](https://github.com/user-attachments/files/18855201/loop_i.txt), relevant IR snippet (full IR [loop_ll.txt](https://github.com/user-attachments/files/18855202/loop_ll.txt) ):
define dso_local noundef i32 @main() local_unnamed_addr #0 {
entry:
br label %for.body
for.body: ; preds = %entry, %for.body
%arrayidx.phi = phi ptr [ @buffer1, %entry ], [ %arrayidx.inc, %for.body ]
%i.017 = phi i32 [ 0, %entry ], [ %inc, %for.body ]
%i.118 = phi i32 [ 0, %entry ], [ %inc8, %for.body ]
%conv = trunc nuw i32 %i.017 to i8
store i8 %conv, ptr %arrayidx.phi, align 1, !tbaa !3
.......
Is having two PHIs valid IR code in the patch context? If so, the assertion EPResumeVal && "must have a resume value for the canonical IV" fails because find_singleton finds two PHIs instead of one and returns null as a consequence. A conservative fix would be to continue without processing EPResumeVal when more than one phi exists, in a manner similar to the functionality this patch replaced. If two PHIs are not valid, well, there's my problem.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
