Re: ping [RFC] [patch] fix PR32893 - forcing alignment >= STACK_BOUNDARY

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

...
> Dorit --
>
> For GCC 4.3, I don't think you have a choice: you need to change the
> vectorized to use plain STACK_BOUNDARY, because that's all the compiler
> can actually support.

ok. Here is the patch that makes the vectorizer consider STACK_BOUNDARY
instead od PREFERRED_STACK_BOUNDARY. If we'll add the proposed
ABI_STACK_BOUNDARY (http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01302.html
) we could replace STACK_BOUNDARY with ABI_STACK_BOUNDARY.

Most of the patch is changes to the vectorizer testcases to account for the
fact that arrays on the stack may not be alignable anymore on targets whose
guaranteed stack alignment is too small. Wherever possible I  globalized
arrays that were originally local. In cases where this changed the behavior
of the test, I also added a version where I left the arrays local and
either removed the alignment checks, or updated them to take into account
"unaligned_stack" targets (or both). For example:
- We can't resolve dependences in tests that have pointers and global
arrays. Therefore, these tests now require run-time dependence testing
(versioning for aliasing) (and this in turn means that we will not peel to
align references, because currently we either version the loop or peel the
loop, so versioning for alignment will be used instead).
- the pass that increases alignment of global arrays (when
-fsection-anchors is on) does not consider arrays within structs. So, when
-fsection-anchors is on (the default on powerpc-linux) we can't change the
alignment of global arrays that are struct fields, and so globalizing these
arrays doesn't help there.
- the same happens with a few cases of multi-dimensional arrays
(vect-[64,65,66].c). Need to check why.
- no-scevccp-outer-6.c changes it's behavior when a local array is
globalized (the loop changes it's forms). Need to check why.

Bootstrapped with vectorization enabled on i386-linux and powerpc64-linux,
tested on the vectorizer testcases on these platforms. To be committed to
mainline.

thanks,
dorit

ChangeLog:

        PR tree-optimization/32893
        * tree-vectorize.c (vect_can_force_dr_alignment_p): Check
        STACK_BOUNDARY instead of PREFERRED_STACK_BOUNDARY.

testsuite/ChangeLog:

        PR tree-optimization/32893
        * testsuite/lib/target-supports.exp
        (check_effective_target_unaligned_stack): new keyword.
        * testsuite/gcc.dg/vect/vect-2.c: Globalize arrays to make the test
        not sensitive to unaligned_stack.
        * testsuite/gcc.dg/vect/vect-3.c: Likewise.
        * testsuite/gcc.dg/vect/vect-4.c: Likewise.
        * testsuite/gcc.dg/vect/vect-5.c: Likewise.
        * testsuite/gcc.dg/vect/vect-6.c: Likewise.
        * testsuite/gcc.dg/vect/vect-7.c: Likewise.
        * testsuite/gcc.dg/vect/vect-13.c: Likewise.
        * testsuite/gcc.dg/vect/vect-17.c: Likewise.
        * testsuite/gcc.dg/vect/vect-18.c: Likewise.
        * testsuite/gcc.dg/vect/vect-19.c: Likewise.
        * testsuite/gcc.dg/vect/vect-20.c: Likewise.
        * testsuite/gcc.dg/vect/vect-21.c: Likewise.
        * testsuite/gcc.dg/vect/vect-22.c: Likewise.
        * testsuite/gcc.dg/vect/vect-27.c: Likewise.
        * testsuite/gcc.dg/vect/vect-29.c: Likewise.
        * testsuite/gcc.dg/vect/vect-64.c: Likewise.
        * testsuite/gcc.dg/vect/vect-65.c: Likewise.
        * testsuite/gcc.dg/vect/vect-66.c: Likewise.
        * testsuite/gcc.dg/vect/vect-72.c: Likewise.
        * testsuite/gcc.dg/vect/vect-73.c: Likewise.
        * testsuite/gcc.dg/vect/vect-86.c: Likewise.
        * testsuite/gcc.dg/vect/vect-all.c: Likewise.
        * testsuite/gcc.dg/vect/slp-25.c: Likewise.
        * testsuite/gcc.dg/vect/wrapv-vect-7.c: Likewise.
        * testsuite/gcc.dg/vect/costmodel/i386/costmodel-vect-31.c:
Likewise.
        * testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-vect-31.c:
Likewise.

        * testsuite/gcc.dg/vect/vect-31.c: Removed alignment checks.
        * testsuite/gcc.dg/vect/vect-34.c: Likewise.
        * testsuite/gcc.dg/vect/vect-36.c: Likewise.
        * testsuite/gcc.dg/vect/vect-64.c: Likewise.
        * testsuite/gcc.dg/vect/vect-65.c: Likewise.
        * testsuite/gcc.dg/vect/vect-66.c: Likewise.
        * testsuite/gcc.dg/vect/vect-68.c: Likewise.
        * testsuite/gcc.dg/vect/vect-76.c: Likewise.
        * testsuite/gcc.dg/vect/vect-77.c: Likewise.
        * testsuite/gcc.dg/vect/vect-78.c: Likewise.

        * testsuite/gcc.dg/vect/no-section-anchors-vect-31.c: New test,
Like the
        original testcase (without no-section-anchors prefix) but with
global arrays.
        * testsuite/gcc.dg/vect/no-section-anchors-vect-34.c: Likewise.
        * testsuite/gcc.dg/vect/no-section-anchors-vect-36.c: Likewsie.
        * testsuite/gcc.dg/vect/no-section-anchors-vect-64.c: Likewise.
        * testsuite/gcc.dg/vect/no-section-anchors-vect-65.c: Likewise.
        * testsuite/gcc.dg/vect/no-section-anchors-vect-66.c: Likewise.
        * testsuite/gcc.dg/vect/no-section-anchors-vect-68.c: Likewise.
        * testsuite/gcc.dg/vect/vect-77-global.c: Likewise.
        * testsuite/gcc.dg/vect/vect-78-global.c: Likewise.

        * testsuite/gcc.dg/vect/vect-77-alignchecks.c: New test. Like the
        original testcase (without no-section-anchors prefix) but fix
alignment checks
        to also consider unaligned_stack targets.
        * testsuite/gcc.dg/vect/vect-78-alignchecks.c: Likewise.

        * testsuite/gcc.dg/vect/no-scevccp-outer-6.c: xfail on
unaligned_stack
        targets.
        * testsuite/gcc.dg/vect/no-scevccp-outer-6-global.c: New test. Like
        no-scevccp-outer-6.c, but with global arrays. xfail for now.

(See attached file: alignmentfix.txt)

> I understand the performance cost, but
> correctness has to trump performance.  ABIs designed to support vector
> instructions will probably ensure that STACK_BOUNDARY is large enough
> that this is not an issue.
>
> What we probably want in the long term is for the compiler (including
> the vectorized) to be able to generate variables with arbitrary
> alignment in all functions.  I would expect the implementation of that
> would be relatively simple; in the function prologue, you would notice
> that this is a function containing a variable of alignment N (greater
> than STACK_BOUNDARY) and generate fixup code to ensure that the stack
> was so aligned.  So, the cost would only be borne by functions with
> variables requiring large alignment, and, even there, it just be a few
> instructions in the prologue.  Perhaps this is as simple as setting
> PREFERRED_STACK_BOUNDARY to max(user-specified-preferred-stack-boundary,
> biggest-alignment-used-in-this-function) at the start of generating RTL
> for a function.
>
> Certainly, I also think that the compiler should generate an error if it
> cannot honor an alignment directive.  For example, in PR 16660, we
> should generate an error on the declaration of "tmp" if we cannot
> actually align it on a 16-byte boundary.
>
> Thanks,
>
> --
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713

Attachment: alignmentfix.txt
Description: Text document