Skip to content
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

Codegen of array initialization generates weird LLVM-IR #1266

Open
orbiri opened this issue Jan 4, 2025 · 3 comments · May be fixed by #1280
Open

Codegen of array initialization generates weird LLVM-IR #1266

orbiri opened this issue Jan 4, 2025 · 3 comments · May be fixed by #1280
Assignees
Labels
good first issue Good for newcomers IR difference A difference in ClangIR-generated LLVM IR that could complicate reusing original CodeGen tests

Comments

@orbiri
Copy link
Collaborator

orbiri commented Jan 4, 2025

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 :)

@orbiri orbiri added good first issue Good for newcomers IR difference A difference in ClangIR-generated LLVM IR that could complicate reusing original CodeGen tests labels Jan 4, 2025
@beamandala
Copy link

Hi, can I work on this issue?

@Lancern
Copy link
Member

Lancern commented Jan 6, 2025

Hi, can I work on this issue?

@beamandala Assigning this to you.

@Rajveer100
Copy link

Rajveer100 commented Jan 12, 2025

@orbiri
Is this fixed? Since as per my reproduction I get:

  store i32 1, ptr @g_arr, align 4
  store i32 2, ptr getelementptr inbounds (i32, ptr @g_arr, i64 1), align 4
  store i32 3, ptr getelementptr inbounds (i32, ptr @g_arr, i64 2), align 4
  %0 = load i32, ptr @g, align 4
  store i32 %0, ptr getelementptr inbounds (i32, ptr @g_arr, i64 3), align 4

Edit: Apologies, ignore my comment, I did the invocation with regular clang instead of CIR.

Rajveer100 added a commit to Rajveer100/clangir that referenced this issue Jan 13, 2025
Rajveer100 added a commit to Rajveer100/clangir that referenced this issue Jan 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers IR difference A difference in ClangIR-generated LLVM IR that could complicate reusing original CodeGen tests
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants