On 31 May 2017 at 16:27, Robin Dapp <rd...@linux.vnet.ibm.com> wrote: >> Since this commit (r248678), I've noticed regressions on some arm targets. >> Executed from: gcc.dg/tree-ssa/tree-ssa.exp >> gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect "Alignment >> of access forced using peeling" 1 >> gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect >> "Vectorizing an unaligned access" 0 >> gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect "Alignment >> of access forced using peeling" 1 >> gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect >> "Vectorizing an unaligned access" 0 >> >> For instance with --target arm-linux-gnueabihf --with-cpu=cortex-a5 >> --with-fpu=vfpv3-d16-fp16 >> (using cortex-a9+neon makes the test pass). > > I do not have access to an arm machine for testing but could these > regressions be "ok" as in we no longer perform peeling because costs for > not peeling <= costs for peeling and we still vectorize? (Just guessing) > Or are these real regressions that prevent vectorization? Does the > "vectorized 1 loops" check fail?
I know it's not very practical, and I would also have to start a manual build with the right config to get all the details because all my builds are in temporary workspaces. I reported only the regressions, so yes "vectorized 1 loops" still passes. Thanks, Christophe > > Regards > Robin >