Information Loss of Array Type in Function Interface in IR Generated by Clang

Dear all,

Hi! Recently, I notice a situation where I cannot infer the size of the outermost dimension of array in the function interface.
To concretely depict the problem, I show the C source code and the generated IR code at the end. The array size of A[] is 51 but this information is lost in the generated IR.
How can I maintain such information in IR? Should I set some argument for Clang so it can do so?
The Clang command I used is :

clang -O1 -emit-llvm -S -g -o tmp.bc

Thanks in advance for your time and suggestion! :slight_smile:

C source code:

int f ( int A[51], int x)
return A[x];

LLVM IR doesn’t maintain a lot of information present in the source. What were you hoping to do with that information? Perhaps you’d be best off doing something up in clang/using the AST uinstead of LLVM IR?

Dear David,

Thanks for your prompt reply!

Sure, I can implement a AST visitor to go through the AST to get the information but I just wonder whether there is any other way to let Clang do so.

What I am considering is how to let the generated IR looks like below, which some tools realize:

define dso_local i32 @_Z1fPii([51 x i32]* %A, i32 %x) local_unnamed_addr #0 !dbg !7 {


There isn’t any option to do that - because it doesn’t model the language accurately (well, ultimately, one of these days, we’ll get rid of pointer types (everything will just be “pointer” (sort of like C’s ‘void*’) - not specific to the thing it points to) at which point none of this will ever be represented in the IR) - the C language ignores the array portion (so you can pass this function a pointer to a single int, or 3 ints, not exactly 51 ints) entirely, degrading it to a pointer as far as semantics are concerned.

Dear David,

Thanks for your detailed explanation! I get it!