[PATCH] Vectorizing Global Structures - Take 2

[Daniel Berlin]

On Fri, Feb 15, 2013 at 12:49 AM, Arnold Schwaighofer <
aschwaighofer at apple.com> wrote:

> On Feb 14, 2013, at 10:21 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
> What I meant by saying "understanding independent objects inside a
>> structure*"* to is that just by looking at an llvm type say for example
>> struct { int A[100]; int B[100]} you and seeing two gep accesses that index
>> into the first and second field of the type you can not necessarily say
>> that the access is not overlapping without fully evaluating the address
>> computation:
>>
>
> Yes, you need to fully evaluate it, but that's not really related to TBAA
> :)
>
>
>
> I was thinking of type trees that encoded fields giving more guarantees
> than LLVM IR currently conveys. Admittedly, I have not though this through,
> whether this could even remotely work for C.
>
> In LLVM IR:
>
> struct { int A[100]; int B[100]} S;
>
> ptr = gep S, 0, 0, x
> ptr2 = gep S, 0, 1, y
>
> = load ptr, !tbaa !"structS::A"
> = load ptr2, !tbaa !"structS::B"
>
> using this you could tell that ptr and ptr2 do not alias without knowing
> about x and y.
>


you've basically just pushed the problem off into the frontend :)
Something needs to know to tag this with structS::A, and not something that
combines structS::A and structS::B.
For simple structure accesses (IE not through pointers), this is certainly
possible.
For any pointer access, it's not possible without pointer analysis.
IE a deference of an int (*[100]) could be an access to structS::A,
structS::B, or some other random type.
Note that your TBAA DAG below does not take this into account.



> Assuming certain language guarantees, which I don't know we could assume
> :).
>



>
> Where the type dag looks something like:
>
>            /->structS::A <- int
> structS->structS::B <- int
>


> In the case of pointer loops that iterate over your example type, it will
> properly discover that it overruns into the next field, and properly mark
> it as pointing-to that field as well.
>
>
> So for the following example it will conservatively say arrayidx and
> arrayidx2 alias?
>
> %struct.anon = type { [256 x i64], i64, [256 x i64] }
>
> define void @foo(i32 %x, i32 %y) {
>   %arrayidx = getelementptr inbounds %struct.anon* @Foo, i32 0, i32 0, i32
> %x
>   %0 = store i64* %arrayidx, align 8
>   %arrayidx2 = getelementptr inbounds %struct.anon* @Foo, i32 0, i32 2,
> i32 %y
>   %1 = store i64* %arrayidx2, align 8
> }
>


Yes, when converted to may-alias info, it will.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130215/7df29f09/attachment.html>