This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, testsuite]: Fix recent vect testsuite failures on x86_64
- From: "Uros Bizjak" <ubizjak at gmail dot com>
- To: "Dorit Nuzman" <DORIT at il dot ibm dot com>
- Cc: "GCC Patches" <gcc-patches at gcc dot gnu dot org>, "Andrew Pinski" <pinskia at gmail dot com>
- Date: Mon, 16 Jul 2007 09:20:22 +0200
- Subject: Re: [PATCH, testsuite]: Fix recent vect testsuite failures on x86_64
- References: <firstname.lastname@example.org> <OF979805D5.2EC5D773-ONC225731A.0025A8FE-C225731A.0026CA82@il.ibm.com>
On 7/16/07, Dorit Nuzman <DORIT@il.ibm.com> wrote:
"Uros Bizjak" <email@example.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,
> > we redefine this function in a way that would fit both spu and x86_64?
> > 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?