Hi Richard,
On 18 September 2017 at 15:57, Richard Sandiford <richard.sandif...@linaro.org> wrote: > Richard Biener <richard.guent...@gmail.com> writes: >> On Mon, Sep 18, 2017 at 1:58 PM, Richard Sandiford >> <richard.sandif...@linaro.org> wrote: >>> The vectoriser aligned vectors to TYPE_ALIGN unconditionally, although >>> there was also a hard-coded assumption that this was equal to the type >>> size. This was inconvenient for SVE for two reasons: >>> >>> - When compiling for a specific power-of-2 SVE vector length, we might >>> want to align to a full vector. However, the TYPE_ALIGN is governed >>> by the ABI alignment, which is 128 bits regardless of size. >>> >>> - For vector-length-agnostic code it doesn't usually make sense to align, >>> since the runtime vector length might not be a power of two. Even for >>> power of two sizes, there's no guarantee that aligning to the previous >>> 16 bytes will be an improveent. >>> >>> This patch therefore adds a target hook to control the preferred >>> vectoriser (as opposed to ABI) alignment. >>> >>> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu. >>> Also tested by comparing the testsuite assembly output on at least one >>> target per CPU directory. OK to install? >> >> Did you specifically choose to pass the hook a vector type rather than >> a mode? > > It seemed like the safest thing to do for the default implementation, > e.g. in case we're vectorising "without SIMD" and thus without an > underlying vector mode. I agree it probably doesn't make much > difference for non-default implementations. > >> I suppose in peeling for alignment the target should be able to >> prevent peeling by returning element alignment from the hook? > > Yeah. This is what the SVE port does in the default vector-length > agnostic mode, and might also make sense in fixed-length mode. > Maybe it would be useful for other targets too, if unaligned accesses > have a negligible penalty for them. > Since this was committed (r253101), I've noticed a regression on arm-none-linux-gnueabihf: FAIL: gcc.dg/vect/vect-multitypes-1.c -flto -ffat-lto-objects scan-tree-dump-times vect "Vectorizing an unaligned access" 4 FAIL: gcc.dg/vect/vect-multitypes-1.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4 for instance, with --target arm-none-linux-gnueabihf --with-mode arm --with-cpu cortex-a9 --with-fpu neon-fp16 Thanks, Christophe > Thanks, > Richard >> Ok. >> >> Thanks, >> Richard.
