[Bug testsuite/84004] [8 regression] gcc.dg/vect/vect-95.c XPASSes

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84004

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
/* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling"
0 "vect" { xfail {vect_element_align} } } } */

but

# Return 1 if the target only requires element alignment for vector accesses

proc check_effective_target_vect_element_align { } {

so I'm not sure why we consider vect_element_align to be a reason to peel?
In fact we don't have a good target to test whether there's likely peeling.
Given the testcase in question:

__attribute__ ((noinline)) int
main1 (int n, float * __restrict__ pd, float * __restrict__ pa, float *
__restrict__ pb, float * __restrict__ pc)
{
  int i;

  for (i = 0; i < n; i++)
    {
      pa[i] = pb[i] * pc[i];
      pd[i] = 5.0;
    }

there are four refs and we can at most align one (unless IPA comes in the
way with LTO).

We have

r164941 | jules | 2010-10-04 16:59:30 +0200 (Mon, 04 Oct 2010) | 40 lines

        gcc/testsuite/
        * gcc.dg/vect/vect-42.c: Use vect_element_align instead of
        vect_hw_misalign.
        * gcc.dg/vect/vect-95.c: Likewise.

but vect_element_align is essentially vect_hw_misalign for most targets.

I'd say we should never peel this for alignment, that just doesn't make
sense.  Some target costs models might disagree but we'll find out...