[PATCH] Vectorizing Global Structures - Take 2

[Arnold Schwaighofer]

On Feb 15, 2013, at 8:46 AM, Renato Golin <renato.golin at linaro.org> wrote:

> On 15 February 2013 12:57, Arnold <aschwaighofer at apple.com> wrote:
> 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, beyond the range of the first array, the behaviour is undefined, which means we can vectorize, even if it does alias, with the excuse that it's better to get it fast where it does matter (defined behaviour) than get correct where it doesn't (undefined behaviour).
> 

> As far as I could see, GCC takes this approach on the examples I attach, and it gets one of the out-of-bounds writes too early (as expected, when aliasing).
> 
> I'm inclined not to mess with aliasing ranges, even if the behaviour is undefined, at least for now, for two reasons:
> 
> 1. LLVM doesn't distinguish between GEP accesses, and can only know what is being accessed (and the possible range) with TBAA.
You don't need TBAA to guarantee in bound accesses (in some cases), it would just make the analysis easier if you can rely on inbound access guaranteed by a sane type system/language rules (which C unfortunately does not have - depending on where you are coming from - low level system hacker or numerical high performance hacker :) ). But I think we agree on this.

> We're already going on step beyond, using bassic AA, I don't want to give two steps at the same time

In clang's standard pass pipeline if you use TBAA you also use BasicAA (to catch obvious type punning idioms and to detect cases that TBAA does not catch).

> 2. As I'm being overly conservative, for now, I prefer to keep the behaviour identical to the non-vectorized code, than risk an avalanche of bug reports, even if they mean undefined behaviour. Since we're changing something delicate, I'd rather make sure it's solid, before start changing undefined behavior.
Agreed.


> 
> So, on this first attempt, I'll bail on the smallest possibility of static aliasing. Of the 7 cases in the attached example, I just want to vectorize the first now.
> 

Ok.

Again, thanks for pushing this Renato.

- Arnold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130215/f73b8505/attachment.html>