[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