"Kewen.Lin" <li...@linux.ibm.com> writes:
> Hi,
>
> As Lyon pointed out, the newly introduced test case
> gcc.dg/tree-ssa/pr96789.c fails on arm-none-linux-gnueabihf.
> Loop vectorizer is able to vectorize the two loops which
> operate on array tmp with load_lanes feature support. It
> makes dse3 get unexpected inputs and do nothing.
>
> This patch is to teach the case to respect vect_load_lanes,
> meanwhile to guard the check only under vect_int.
I'm not sure this is the right check. The test passes on aarch64,
which also has load lanes, but apparently doesn't use them for this
test. I think the way the loop vectoriser handles the loops will
depend a lot on target costs, which can vary in unpredictable ways.
Does it work if you instead change -ftree-vectorize to -ftree-slp-vectorize?
Or does that defeat the purpose of the test?
Thanks,
Richard
>
> Is it ok for trunk?
>
> BR,
> Kewen
> -----
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/tree-ssa/pr96789.c: Adjusted by excluding vect_load_lanes.
>
>
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr96789.c
> b/gcc/testsuite/gcc.dg/tree-ssa/pr96789.c
> index d6139a014d8..1b89f8b7a6a 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/pr96789.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr96789.c
> @@ -55,4 +55,7 @@ bar (int16_t res[16], uint8_t *val1, uint8_t *val2)
> }
> }
>
> -/* { dg-final { scan-tree-dump {Deleted dead store:.*tmp} "dse3" } } */
> +/* Exclude targets which support load_lanes since loop vectorizer
> + can vectorize those two loops that operate tmp array so that
> + subsequent dse3 will not eliminate tmp stores. */
> +/* { dg-final { scan-tree-dump {Deleted dead store:.*tmp} "dse3" { target {
> vect_int && { ! vect_load_lanes } } } } } */
