ping^3 ? https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01063.html
On 31 August 2017 at 11:22, Christophe Lyon <christophe.l...@linaro.org> wrote: > ping^2 ? > > > On 21 August 2017 at 15:04, Christophe Lyon <christophe.l...@linaro.org> > wrote: >> ping ? >> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01063.html >> >> Christophe >> >> >> On 18 July 2017 at 14:50, Christophe Lyon <christophe.l...@linaro.org> wrote: >>> Hello, >>> >>> I've received a complaint that GCC for AArch64 would generate >>> vectorized code relying on unaligned memory accesses even when using >>> -mstrict-align. This is a problem for code where such accesses lead to >>> memory faults. >>> >>> A previous patch (r243333) introduced >>> aarch64_builtin_support_vector_misalignment, which rejects such >>> accesses when the element size is 64 bits, and accept them otherwise, >>> which I think it shouldn't. The testcase added at that time only used >>> 64 bits elements, and therefore didn't fully test the patch. >>> >>> The report I received is about vectorized accesses to an array of >>> unsigned chars, whose start address is not aligned on a 128 bits >>> boundary. >>> >>> The attached patch fixes the problem by making >>> aarch64_builtin_support_vector_misalignment always return false when >>> the misalignment is not known at compile time. >>> >>> I've also added a testcase, which tries to check if the array start >>> address alignment is checked (using %16, and-ing with #15), so that >>> loop peeling is performed *before* using vectorized accesses. Without >>> the patch, vectorized accesses are used at the beginning of the array, >>> and byte accesses are used for the remainder at the end, and there is >>> not such 'and wX,wX,15'. >>> >>> BTW, I'm not sure about the same hook for arm... it seems to me it has >>> a similar problem. >>> >>> OK? >>> >>> Thanks, >>> >>> Christophe
