[PATCH] Vectorizing Global Structures - Take 2

Renato Golin renato.golin at linaro.org
Fri Feb 15 06:46:40 PST 2013


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. We're already going on
step beyond, using bassic AA, I don't want to give two steps at the same
time

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 behaviour.

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.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130215/69941496/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alias.zip
Type: application/zip
Size: 2190 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130215/69941496/attachment.zip>


More information about the llvm-commits mailing list