On 07/08/12 16:04, Richard Guenther wrote: > On Tue, Aug 7, 2012 at 4:56 PM, Ulrich Weigand <uweig...@de.ibm.com> wrote: >> Richard Guenther wrote: >>> On Fri, Jul 27, 2012 at 5:24 PM, Ulrich Weigand <uweig...@de.ibm.com> wrote: >>>> ChangeLog: >>>> >>>> * target.def (vector_alignment): New target hook. >>>> * doc/tm.texi.in (TARGET_VECTOR_ALIGNMENT): Document new hook. >>>> * doc/tm.texi: Regenerate. >>>> * targhooks.c (default_vector_alignment): New function. >>>> * targhooks.h (default_vector_alignment): Add prototype. >>>> * stor-layout.c (layout_type): Use targetm.vector_alignment. >>>> * config/arm/arm.c (arm_vector_alignment): New function. >>>> (TARGET_VECTOR_ALIGNMENT): Define. >>>> >>>> * tree-vect-data-refs.c (vect_update_misalignment_for_peel): Use >>>> vector type alignment instead of size. >>>> * tree-vect-loop-manip.c (vect_do_peeling_for_loop_bound): Use >>>> element type size directly instead of computing it from alignment. >>>> Fix variable naming and comment. >>>> >>>> testsuite/ChangeLog: >>>> >>>> * lib/target-supports.exp >>>> (check_effective_target_vect_natural_alignment): New function. >>>> * gcc.dg/align-2.c: Only run on targets with natural alignment >>>> of vector types. >>>> * gcc.dg/vect/slp-25.c: Adjust tests for targets without natural >>>> alignment of vector types. >> >> >>>> OK for mainline? >>> >>> Ok. >> >> Would it be OK to backport this to 4.7 and possibly 4.6? >> >> This patch represents a change in the ABI on ARM (the alignment could >> potentially affect struct member offsets, for example), which could >> conceivably cause incompatibilities with code compiled with older >> versions of GCC. We had originally decided we nevertheless want to >> implement this change on ARM, because: >> >> - GCC is now in compliance with the platform ABI document >> - the old code could actually be buggy since GCC *assumed* 16-byte >> alignment that wasn't actually guaranteed >> - code actually affected by this change ought to be rare (code using >> NEON vector types is rare in the first place, code using *structure >> members* of such types is even rarer, and code using such structures >> in cross-module APIs seems to be extremely rare) >> >> Nevertheless, given we do want to make this change, it would be best >> to roll it out as quickly as possible, to minimize the time period >> where people might use old (not yet fixed) compilers to generate >> non-ABI-compliant binaries. Thus, we think it would be good for >> the change to be applied to all still open release branches as well. >> >> (Note that while the patch contains changes to common code, those >> should be no-ops for all targets that do not implement the new hook.) > > I'll defer the decision to the target maintainers. But please double-check > for any changes in the vectorizer parts when backporting to 4.6. >
My inclination is to back-port this to all maintained branches (for consistency). However, it does need to be release-noted. R.
