-
Notifications
You must be signed in to change notification settings - Fork 160
Closed
Labels
IR differenceA difference in ClangIR-generated LLVM IR that could complicate reusing original CodeGen testsA difference in ClangIR-generated LLVM IR that could complicate reusing original CodeGen testsgood first issueGood for newcomersGood for newcomers
Description
When generating LLVM-IR through CIR for the following code:
int g = 5;
int g_arr[5] = {1, 2, 3, g};
We get the following LLVM-IR:
store i32 1, ptr @g_arr, align 4
store i32 2, ptr getelementptr (i32, ptr @g_arr, i64 1), align 4
store i32 3, ptr getelementptr (i32, ptr getelementptr (i32, ptr @g_arr, i64 1), i64 1), align 4
%2 = load i32, ptr @g, align 4
store i32 %2, ptr getelementptr (i32, ptr getelementptr (i32, ptr getelementptr (i32, ptr @g_arr, i64 1), i64 1), i64 1), align 4
Notices the triple GEP(GEP(GEP(arr,1),1),1) for the last store. Clang generates a sane GEP(arr,3)
for that in codegen.
The root cause is in the way the codegen is written in CIRGenExprAgg.cpp
in AggExprEmitter::emitArrayInit
.
Would be nice to get to parity here :)
bcardosolopes
Metadata
Metadata
Assignees
Labels
IR differenceA difference in ClangIR-generated LLVM IR that could complicate reusing original CodeGen testsA difference in ClangIR-generated LLVM IR that could complicate reusing original CodeGen testsgood first issueGood for newcomersGood for newcomers