[llvm-dev] Field sensitive alias analysis?
Pete Cooper via llvm-dev
llvm-dev at lists.llvm.org
Thu Dec 10 11:00:16 PST 2015
> On Dec 10, 2015, at 8:09 AM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
>
> Opps, you are right in my example basicaaa could do it potentially. Correct example is slightly different:
> int foo(struct S *ps, int i) {
> ps->a[i] = 1;
> ps->b = 2;
> return ps->a[i];
> }
> Here basicaa cannot make sure that 'ps->a[i]' doesn't change after 'ps->b = 2' because if 'i == 10' all 3 memory accesses will read/write the same memory. And type information about S::a is required to disambiguate. With current TBAA 'ps->a[i]' is about random 'int' read.
>
> Yes, and without more info, in LLVM that read can legally touch ps->b.
I thought the inbounds on the GEPs would have told us that the a[] accesses and b access are both in bounds of their respective fields of the struct.
Or does inbounds only tell us that the GEPs are in bounds of ‘ps’ itself?
> So that makes sense.
>
>
> Missing information here is the range inside struct S that could be accessed.
>
> What do you mean by "could be accessed". Do you mean "valid to access in C"?
>
> By access I meant read/write memory i.e. that size of S::a inside the struct or at least information that only S::a is accessed in this place i.e. not S::b.
>
> Okay.
>
> So what you want sounds reasonable to me ;-)
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151210/efa9cfa8/attachment-0001.html>
More information about the llvm-dev
mailing list