[PATCH, testsuite]: Fix recent vect testsuite failures on x86_64

[Dorit Nuzman]

...
> > > Hm, for x86_64 we have:
> > >
> > >   /* x86-64 ABI requires arrays greater than 16 bytes to be aligned
> > >      to 16byte boundary.  */
> > >   if (TARGET_64BIT)
> > >     {
> > >       if (AGGREGATE_TYPE_P (type)
> > >       && TYPE_SIZE (type)
> > >       && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST
> > >       && (TREE_INT_CST_LOW (TYPE_SIZE (type)) >= 128
> > >           || TREE_INT_CST_HIGH (TYPE_SIZE (type))) && align < 128)
> > >    return 128;
> > >     }
> > >
> > > So this alignment exception applies only to arrays. There is no
> > > guarantee, that i.e. some unrelated sequence of floats will be
aligned
> > > to vector alignement boundary.
> >
> > If we really want to be accurate, we should probably also reconsider if
> > using vect_aligned_arrays in the testcase pr25413a.c is appropriate
(there
> > we are dealing with a pointer, not an array). In pr25413a.c, does the
> > vectorizer figure out that vector alignment is reachable on x86_64
because
> > it can determine that the alignment is at least 16bytes, or because it
> > calls the target builtin vector_alignment_reachable, whose default
> > implementation returns true (cause it's not packed and the type-size is
not
> > bigger than a pointer-size)?  If it's the latter, then it has nothing
to do
> > with array alignment, and we probably want a separate target keyword
for
> > that (I guess the vector_alignment_reachable will return true for all
64bit
> > targets, so maybe we don't really need a new keyword here).
>
> Hm, for pr25413a.c, it looks that malloc on 32bit targets doesn't
> return correctly aligned address that would satisfy vectorizer
> constraint. However - if we can detect this, could we use unaligned
> loads in this case?
>

Not sure I understand what you're asking - in pr25413a.c there are no
loads, only a store. In general, we could and we do use unaligned loads
when we need to. It's just that currently unaligned stores are not
implemented and the way we deal with it is by peeling the loop to align the
store (and if that's not doable, we do loop versioning).

dorit

> Uros.