Suitable regression test for vectorizer patches?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Suitable regression test for vectorizer patches?

Joern Wolfgang Rennecke-2
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.
Reply | Threaded
Open this post in threaded view
|

Re: Suitable regression test for vectorizer patches?

Richard Biener-2
On Mon, Oct 29, 2018 at 7:03 PM Joern Wolfgang Rennecke
<[hidden email]> wrote:
>
> 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.

> 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.


>
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Suitable regression test for vectorizer patches? - (need {u,}madd* pattern)

Joern Wolfgang Rennecke-2

On 30/10/18 08:36, Richard Biener wrote:
> On Mon, Oct 29, 2018 at 7:03 PM Joern Wolfgang Rennecke
> <[hidden email]> wrote:
>> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Suitable regression test for vectorizer patches? - (need {u,}madd* pattern)

Ramana Radhakrishnan [on liliput]
On Thu, Nov 1, 2018 at 10:42 AM Joern Wolfgang Rennecke
<[hidden email]> wrote:

>
>
> On 30/10/18 08:36, Richard Biener wrote:
> > On Mon, Oct 29, 2018 at 7:03 PM Joern Wolfgang Rennecke
> > <[hidden email]> wrote:
> >> 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?

Don't think there's a single instruction that does that.

smlad is the closest IIRC and checking with the Arm ARM, that's V2HI
-> V2HI for the multiplication and then an accumulation with a 32 bit
accumulator. Thus effectively a  add (reduc_add (mult(v2hi , v2hi)),
si) , but we don't support any vector forms using the integer register
set for the M profile architecture as of today in gcc. Thus you
probably need 2 smlald instructions to achieve this IIUC . We do have
a dot product optab in the arm backend but that's with Advanced simd
which isn't in the M profile.

regards
Ramana



>
> 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.