[PATCH 4/5 v3] Vect peeling cost model

[Christophe Lyon]

On 31 May 2017 at 16:27, Robin Dapp <rdapp@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
>