CIR generated LLVM code for pointer arithmetic misses inbounds

[ghehg]

sample code
void foo(int *iptr) { iptr + 2; }

Clang generated code:
https://godbolt.org/z/8Yjnhxhz4
where we have
getelementptr inbounds i32, ptr %0, i64 2
CIR generated LLVM code is like
https://godbolt.org/z/Wzdcvea46
where we see
getelementptr i32, ptr %3, i64 2,
We are missing inbounds here.

[ghehg]

up for take.
If nobody picks it up, I'll fix it next week

[liusy58]

I can work on it to learn ClangIR.

[smeenai]

@liusy58 welcome aboard! The website has some useful resources, and the Discord channel (use this link to join the LLVM Discord server if you haven't already) is a great place to ask questions (as is this issue). The general idea here would be to find the code in clang/lib/CodeGen that adds the appropriate attributes and then make the corresponding change under clang/lib/CIR/CodeGen.

[liusy58]

Thank you! I know that ClangIR is good for analysis and can make c++ safer. Apart from this, can we do something else?

[ghehg]

Thank you! I know that ClangIR is good for analysis and can make c++ safer. Apart from this, can we do something else?

Thanks for willing to help out! Along this line of IR differences, depending on your interests, there are a couple of issues in my mind that we could use help.

1. Support for elementwise builtins . Those could be really useful for vector intensive programs that use those builtins. And since relevant Ops are already defined in CIR and support vector type now, this should be a relatively starter rampup work.
2. Comparing to classic clang codegen, CIR codegen still misses function call site and parameter attributes in the generated LLVM IR.

I'll create issues for above 2 issues by next Monday.

[liusy58]

Interesting topics. I love this!

[ghehg]

Interesting topics. I love this!
First issue: elementwise builtins
#1192
The second issue already filed
#1039

[liusy58]

Ok, thank you!