This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 7/16/07, Dorit Nuzman <DORIT@il.ibm.com> wrote:

"Uros Bizjak" <ubizjak@gmail.com> wrote on 16/07/2007 09:14:23:

> On 7/15/07, Dorit Nuzman <DORIT@il.ibm.com> wrote:
>
> > *naturally* aligned (i.e. aligned on their type-size boundary). Uros,
can
> > we redefine this function in a way that would fit both spu and x86_64?
Say,
> > that data-types are guaranteed to be at least naturally aligned?
>
> 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?

Uros.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]