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. > 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... R.
