[PATCH] Vectorizing Global Structures - Take 2
Arnold
aschwaighofer at apple.com
Fri Feb 15 04:57:01 PST 2013
Sent from my iPhone
On Feb 15, 2013, at 3:46 AM, Renato Golin <renato.golin at linaro.org> wrote:
> On 15 February 2013 05:49, Arnold Schwaighofer <aschwaighofer at apple.com> wrote:
>> 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. Assuming certain language guarantees, which I don't know we could assume :).
>
> Without inspecting the induction range and step, I don't know if you can ever say they don't alias.
>
> C allows you to do:
>
> A[150] = B[51];
>
> And if you rely only on the type being different, you might say then don't alias, when they actually do.
>
Yes this is where I am not sure whether C's strict aliasing would allow or forbid that kind of access.
I know it forbids a float * aliasing an int * but it does it forbit struct.a[x] aliasing struct.b[x]?
If it allows it then yes all my example won't work. You would need a different language that had such a semantic that would guarantee that such accesses are not allowed.
>
>> 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
>> }
>
> It's still valid C to do A[300] and end up reading B.
Yes, precisely and it's also valid in llvm ir semantics.
>
> In that form, I'd never try to do anything with that function, not without enough RT checks. ;)
>
> --renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130215/aa7fc755/attachment.html>
More information about the llvm-commits
mailing list