[PATCH] D20665: Claim NoAlias if two GEPs index different fields of the same struct

Daniel Berlin via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 22 14:03:08 PDT 2016


Hey taewook,


On Tue, Jun 14, 2016 at 1:14 PM, Taewook Oh <twoh at fb.com> wrote:

> twoh added a comment.
>
> @dberlin I meant the same level of type information as tbaa for GEP's
> pointer operand.
>
>
But i guess i don't see how that helps, as it doesn't matter until you see
a load . So why wouldn't you just annotate the load directly?


> For eli's example above, if the original access were to the array field of
> the struct, clang generates GEP like
>
>   %20 = load %struct.A*, %struct.A** %3, align 8
>   %21 = getelementptr inbounds %struct.A, %struct.A* %20, i32 0, i32 0
>   %22 = getelementptr inbounds [10 x i8], [10 x i8]* %21, i64 0, i64 %19
>
> But if the access were to char* casted pointer, then it is like
>
>   %20 = load %struct.A*, %struct.A** %3, align 8
>   %21 = bitcast %struct.A* %20 to i8*
>   %22 = getelementptr inbounds i8, i8* %21, i64 %19
>
> and these instructions are eventually combined to
>
>   %10 = getelementptr inbounds %struct.A, %struct.A* %0, i64 0, i32 0, i64
> %9
>
> So by knowing the original pointer operand type of GEP, it is possible to
> tell if the original accesses were to the field of the struct itself or to
> the casted pointer, assuming that clang generates bitscast operation for
> every type casting.
>

You are not guaranteed that llvm types, fields, etc, have *any* relation to
source ones, so again, i guess i don't see what this helps.

The type of metadata i would see helping for you would simply by something
like tbaa struct path data with no types attached.  IE you just want to
know if the accesses are to things C considers different fields.



>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D20665
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160622/88f36f2b/attachment.html>


More information about the llvm-commits mailing list