Suitable regression test for vectorizer patches?

[Joern Wolfgang Rennecke]

I want to submit some vectorizer patches, what would be a suitable
regression test?
Preferably some native or cross test that can run on an i7 x86_64
GNU/Linux machine.

To give an idea what code I'm patching, here are the patches I got so far:

* tree-vect-patterns.c (vect_recog_dot_prod_pattern): Recognize
unsigned dot product pattern.

Allow widening multiply-add to be used for DOT_PROF_EXPR reductions.
* tree-vect-data-refs.c (vect_get_smallest_scalar_type):
Treat WIDEN_MULT_PLUS_EXPR like WIDEN_SUM_EXPR.
* tree-vect-loop.c (get_initial_def_for_reduction): Likewise.
Get VECTYPE from STMT_VINFO_VECTYPE.
(vect_determine_vectorization_factor):
Allow vcector size input/output mismatch for reduction.
(vect_analyze_scalar_cycles_1): When we find a phi for a reduction,
put the reduction statement into the phi's STMT_VINFO_RELATED_STMT.
* tree-vect-patterns.c (vect_pattern_recog_1): If DOT_PROD_EXPR
can't
be expanded directly, try to use WIDEN_MULT_PLUS_EXPR instead.

Fix bug where a vectorizer reduction split (from
TARGET_VECTORIZE_SPLIT_REDUCTION)
would end up not being used.
* tree-vect-loop.c (vect_create_epilog_for_reduction):
If we split the reduction, use the result in Case 3 too.

[Richard Biener]

On Mon, Oct 29, 2018 at 7:03 PM Joern Wolfgang Rennecke

Post by Joern Wolfgang Rennecke
I want to submit some vectorizer patches, what would be a suitable
regression test?

I am sure you have testcases, no? For new features please make them
dg-do run ones by checking correctness.

Post by Joern Wolfgang Rennecke
Preferably some native or cross test that can run on an i7 x86_64
GNU/Linux machine.

You are probably talking about the need for specific HW features?
We have dg-requires-effective-target FOO where IIRC there are
ones that enable extra options for compilation (look for avx-runtime
or so for example).

Richard.

Post by Joern Wolfgang Rennecke
* tree-vect-patterns.c (vect_recog_dot_prod_pattern): Recognize
unsigned dot product pattern.
Allow widening multiply-add to be used for DOT_PROF_EXPR reductions.
Treat WIDEN_MULT_PLUS_EXPR like WIDEN_SUM_EXPR.
* tree-vect-loop.c (get_initial_def_for_reduction): Likewise.
Get VECTYPE from STMT_VINFO_VECTYPE.
Allow vcector size input/output mismatch for reduction.
(vect_analyze_scalar_cycles_1): When we find a phi for a reduction,
put the reduction statement into the phi's STMT_VINFO_RELATED_STMT.
* tree-vect-patterns.c (vect_pattern_recog_1): If DOT_PROD_EXPR
can't
be expanded directly, try to use WIDEN_MULT_PLUS_EXPR instead.
Fix bug where a vectorizer reduction split (from
TARGET_VECTORIZE_SPLIT_REDUCTION)
would end up not being used.
If we split the reduction, use the result in Case 3 too.

[Joern Wolfgang Rennecke]

Post by Richard Biener
On Mon, Oct 29, 2018 at 7:03 PM Joern Wolfgang Rennecke

Post by Joern Wolfgang Rennecke
I want to submit some vectorizer patches, what would be a suitable
regression test?

I am sure you have testcases, no? For new features please make them
dg-do run ones by checking correctness.

For the dot product / widen_sum -> madd transformations to trigger,
I need an in-tree port with a named pattern matched by
smadd_widen_optab or umadd_widen_optab, with an input matching
PREFERRED_SIMD_VECTOR_MODE, and hence an output twice that
size (and that pattern must not be eclipsed by existing
[us]sum_widen_optab and [us]dot_prod_optab matches).

I can't find any such port in the tree. Indeed, not any
{u,}madd<vector_in_mode><vector_out_mode>4 pattern at all.

I've heard that arm cortex-m4 hardware acctually supports a madd vector
operation
(V2HI -> V2SI), is that true?

Would the test be suitable if it made the arm target,
with a patch added to add a suitable madd pattern, and my vectorizer
patch added,
use that madd pattern?

Or could I add an imaginary madd vector extension instruction to the arc for
that purpose? But then, it wouldn't actually execute, as it's just a
made-up instruction;
nor would the vectorization test be included in a test run for an actual.