[llvm-dev] Identify c-style pointer to array
alex via llvm-dev
llvm-dev at lists.llvm.org
Tue Jul 25 09:03:48 PDT 2017
> Not usually. C has a rarely used feature to tell the compiler how big
> an array going into a function is:
>
> void foo(int arr[static 5]) {}
>
> With this Clang will add a "dereferenceable(20)" attribute to the
> parameter that does roughly what you're asking. But without that
> you're not allowed to assume anything about the "array" so even
> knowing it was an array is largely pointless at the LLVM level.
>
> Another alternative if you control the C is to pass a pointer to an array:
>
> void foo(int (*arr)[5]) {}
>
> This will come through to LLVM as "[5 x i32]*" which you can in the type system.
>
> Cheers.
>
> Tim.
Hi Tim,
hmm, currently, I'm using the fixed size arrays (as you suggested). This
is fine for self written c code (when we don't need dynamic sized arrays).
However, c code like
int i=5;
double dArr[i];
dArr[2]=42.0;
in IR translates to a double * of type pointer to double, not aggregate
type;
The last line in IR translates to (vla relates to the is the dynamically
allocated array):
%arrayidx = getelementptr inbounds double* %vla, i64 3
store double 4.200000e+01, double* %arrayidx, align 8
which is different to the usual aggregate style call (with leading i32 0):
%arrayidx = getelementptr inbounds [5 x double]* %0, i32 0, i64 3
I thought the getelemtptr call using 'inbounds' would return a poison
value if the index is out of bounds -> a naive approach would be to
iterate from 0 upwards, try to introduce a gep instruction and stopping
at the first poison value.
This approach however is cumbersome, as I would need to check every
pointer that way to see if it actually relates to an array....
Alex
More information about the llvm-dev
mailing list