On Mon, Jun 11, 2012 at 5:25 PM, Richard Earnshaw <rearn...@arm.com> wrote: > On 11/06/12 15:53, Richard Guenther wrote: >> On Mon, Jun 11, 2012 at 4:38 PM, Richard Earnshaw <rearn...@arm.com> wrote: >>> On 11/06/12 15:17, Richard Guenther wrote: >>>> On Mon, Jun 11, 2012 at 3:16 PM, Richard Earnshaw <rearn...@arm.com> wrote: >>>>> The ARM ABI states that vectors larger than 64 bits in size still have >>>>> 64-bit alignment; never-the-less, the HW supports alignment hints of up >>>>> to 128-bits in some cases and will trap in a vector has an alignment >>>>> that less than the hint. GCC currently hard-codes larger vectors to be >>>>> aligned by the size of the vector, which means that 128-bit vectors are >>>>> marked as being 128-bit aligned. >>>>> >>>>> The ARM ABI unfortunately does not support generating such alignment for >>>>> parameters passed by value and this can lead to traps at run time. It >>>>> seems that the best way to solve this problem is to allow the back-end >>>>> to set an upper limit on the alignment permitted for a vector. >>>>> >>>>> I've implemented this as a separate hook, rather than using the existing >>>>> hooks because there's a strong likelihood of breaking some existing ABIs >>>>> if I did it another way. >>>>> >>>>> There are a couple of tests that will need some re-working before this >>>>> can be committed to deal with the fall-out of making this change; I'll >>>>> prepare those changes if this patch is deemed generally acceptable. >>>> >>>> Hm. Where would you use that target hook? >>>> >>> >>> Doh! >>> >>> It was supposed to be in the patch set... :-( >>> >>> in layout_type(), where the alignment of a vector is forced to the size >>> of the vector. >> >> Ok. >> >> + /* Naturally align vectors, but let the target set an upper >> + limit. This prevents ABI changes depending on whether or >> + not native vector modes are supported. */ >> + TYPE_ALIGN (type) >> + = targetm.vector_alignment (type, tree_low_cst (TYPE_SIZE (type), >> 0)); >> >> The type argument or the size argument looks redundant. > > Technically, yes, we could get rid of "tree_low_cst (TYPE_SIZE (type)" > and calculate it inside the alignment function if it was needed. > However, it seemed likely that most targets would need that number one > way or another, such that passing it would be helpful.
Well, you don't need it in stor-layout and targets might think the value may be completely unrelated to the type ... >> Note that we still >> can have such vector "properly" aligned, thus the vectorizer would need to >> use build_aligned_type also if it knows the type is aligned, not only when >> it thinks it is misaligned. You basically change the alignment of the >> "default" >> vector type. >> > > I'm not sure I follow... I say that a large vector may be still aligned, so the vectorizer when creating vector memory references has to use a non-default aligned vector type when the vector is aligned. It won't do that at the moment. Richard. > R. > > >
