[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