Re: [patch] [PR25413] fix natural-alignment assumption in the vectorizer

[Dorit Nuzman <DORIT at il dot ibm dot com>]

>
> Hi,
>
> This is a slightly revised and updated resubmission of this patch:
> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00167.html
> It fixes PR25413, and hopefully also PR32093 and the zlib breakage
> mentioned here:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32093#c2.
>

Just to clarify, I need approval for the target-specific bits in rs6000.c
(implementation of the new target builtin). (Comments for the rest of the
patch are of course welcome as well). As mentioned before, the
implementation for the target builtin (both the default one and the rs6000
one) makes us more conservative than we are now, so these should be safe to
incorporate.

thanks,
dorit


> The vectorizer assumes that all data is naturally aligned on the size of
> its data-type. This is not always the case. Packed structs are one
example.
> Another example is 64-bit doubles which, on some targets, are not
> guaranteed to be aligned on 64-bit boundary. With this patch, when the
> vectorizer cannot prove that a data-reference is naturally aligned it
> avoids using loop-peeling as a means to align this data-reference (cause
it
> cannot work). This is done in a new function -
vector_alignment_reachable_p
> - which also contains some code that was factored out from
> vect_enhance_data_refs_alignment. It adds a new target-builtin, a default
> implementation for it in default_builtin_vector_alignment_reachable, and
> also an rs6000 implementation for it. Maybe target-specific
implementations
> for other targets are appropriate as well (*). I'm not 100% sure about
the
> rs6000 implementation, but even if it's not accurate enough, it is still
an
> improvement over the current situation.
>
> Bootstrapped on powerpc-linux, passed the vectorizer testcases, and going
> through full regression testing.
> Also bootstrapped on i386-linux, and passed full regression testing.
>
> (*) Also included in the patch is a suggested implementation of the
target
> hook for the SPU. If this is approved and applied we'd also need to xfail
> the current dg-final checks for spu-*-* in pr25413.c, pr25413a.c,
> pr31699.c, because on the SPU longs and doubles are natually aligned
> (right?), so we can use peeling there. For the SPU I only tested that the
> patch builds with a cross-compile for c only, and checked that the 3
tests
> above run ok. So this requires more thorough testing (If someone can help
> with this it would be most appreciated...).
>
> OK for mainline?
>
> :ADDPATCH middle-end,rs6000:
>
> thanks,
> dorit
>
> 2007-07-02  Dorit Nuzman  <dorit@il.ibm.com>
>             Devang Patel  <dpatel@apple.com>
>
>         PR tree-optimization/25413
>         * targhooks.c (default_builtin_vector_alignment_reachable): New.
>         * targhooks.h (default_builtin_vector_alignment_reachable): New.
>         * tree.h (contains_packed_reference): New.
>         * expr.c (contains_packed_reference): New.
>         * tree-vect-analyze.c (vector_alignment_reachable_p): New.
>         (vect_enhance_data_refs_alignment): Call
> vector_alignment_reachable_p.
>         * target.h (vector_alignment_reachable): New builtin.
>         * target-def.h (TARGET_VECTOR_ALIGNMENT_REACHABLE): New.
>         * config/rs6000/rs6000.c (rs6000_vector_alignment_reachable):
New.
>         (TARGET_VECTOR_ALIGNMENT_REACHABLE): Define.
>
> 2007-07-02  Dorit Nuzman  <dorit@il.ibm.com>
>             Devang Patel  <dpatel@apple.com>
>
>         PR tree-optimization/25413
>         * gcc.dg/vect/vect-align-1.c: New.
>         * gcc.dg/vect/vect-align-2.c: New.
>         * gcc.dg/vect/pr25413.c: New.
>         * gcc.dg/vect/pr25413a.c: New.
>         * gcc.dg/vect/pr31699.c: Fix dg-final check.
>
> (See attached file: pr25413.july2.txt)[attachment "pr25413.july2.
> txt" deleted by Dorit Nuzman/Haifa/IBM]