tree-optimization/103641 - improve vect_synth_mult_by_constant

  The following happens to improve compile-time of the PR103641
testcase on aarch64 significantly.  I did not investigate the
effect on the generated code but at least in theory
choose_mult_variant should do a better job when we tell it
the actual mode we are going to use for the operations it
synthesizes.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

OK for trunk?

Thanks,
Richard.

2022-02-04  Richard Biener  <rguenther@suse.de>

	PR tree-optimization/103641
	* tree-vect-patterns.cc (vect_synth_mult_by_constant):
	Pass the vector mode to choose_mult_variant.
---
 gcc/tree-vect-patterns.cc | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
  

Richard Biener <rguenther@suse.de> writes:
> The following happens to improve compile-time of the PR103641
> testcase on aarch64 significantly.  I did not investigate the
> effect on the generated code but at least in theory
> choose_mult_variant should do a better job when we tell it
> the actual mode we are going to use for the operations it
> synthesizes.

Yeah, agreed.  (Following up from a comment in the PR: I don't think
we can rely on unsupported operations having a high cost, but then we
should already be checking that the operations are actually supported.)

> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> OK for trunk?
>
> Thanks,
> Richard.
>
> 2022-02-04  Richard Biener  <rguenther@suse.de>
>
> 	PR tree-optimization/103641
> 	* tree-vect-patterns.cc (vect_synth_mult_by_constant):
> 	Pass the vector mode to choose_mult_variant.
> ---
>  gcc/tree-vect-patterns.cc | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc
> index bea04992160..686a10caec1 100644
> --- a/gcc/tree-vect-patterns.cc
> +++ b/gcc/tree-vect-patterns.cc
> @@ -3046,17 +3046,17 @@ vect_synth_mult_by_constant (vec_info *vinfo, tree op, tree val,
>       can synthesize shifts that way.  */
>    bool synth_shift_p = !vect_supportable_shift (vinfo, LSHIFT_EXPR, multtype);
>  
> +  tree vectype = get_vectype_for_scalar_type (vinfo, multtype);
>    HOST_WIDE_INT hwval = tree_to_shwi (val);
>    /* Use MAX_COST here as we don't want to limit the sequence on rtx costs.
>       The vectorizer's benefit analysis will decide whether it's beneficial
>       to do this.  */
> -  bool possible = choose_mult_variant (mode, hwval, &alg,
> -					&variant, MAX_COST);
> +  bool possible = choose_mult_variant (VECTOR_MODE_P (TYPE_MODE (vectype))
> +				       ? TYPE_MODE (vectype) : mode,
> +				       hwval, &alg, &variant, MAX_COST);
>    if (!possible)
>      return NULL;
>  
> -  tree vectype = get_vectype_for_scalar_type (vinfo, multtype);
> -
>    if (!vectype
>        || !target_supports_mult_synth_alg (&alg, variant,
>  					   vectype, synth_shift_p))

The !vectype early out needs to move with the assignment.
LGTM otherwise.

Thanks,
Richard
  

On Fri, Feb 04, 2022 at 09:31:20AM +0100, Richard Biener wrote:
> The following happens to improve compile-time of the PR103641
> testcase on aarch64 significantly.  I did not investigate the
> effect on the generated code but at least in theory
> choose_mult_variant should do a better job when we tell it
> the actual mode we are going to use for the operations it
> synthesizes.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
> 
> OK for trunk?
> 
> Thanks,
> Richard.
> 
> 2022-02-04  Richard Biener  <rguenther@suse.de>
> 
> 	PR tree-optimization/103641
> 	* tree-vect-patterns.cc (vect_synth_mult_by_constant):
> 	Pass the vector mode to choose_mult_variant.

LGTM.

	Jakub
  

On Fri, 4 Feb 2022, Richard Sandiford wrote:

> Richard Biener <rguenther@suse.de> writes:
> > The following happens to improve compile-time of the PR103641
> > testcase on aarch64 significantly.  I did not investigate the
> > effect on the generated code but at least in theory
> > choose_mult_variant should do a better job when we tell it
> > the actual mode we are going to use for the operations it
> > synthesizes.
> 
> Yeah, agreed.  (Following up from a comment in the PR: I don't think
> we can rely on unsupported operations having a high cost, but then we
> should already be checking that the operations are actually supported.)
> 
> > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> >
> > OK for trunk?
> >
> > Thanks,
> > Richard.
> >
> > 2022-02-04  Richard Biener  <rguenther@suse.de>
> >
> > 	PR tree-optimization/103641
> > 	* tree-vect-patterns.cc (vect_synth_mult_by_constant):
> > 	Pass the vector mode to choose_mult_variant.
> > ---
> >  gcc/tree-vect-patterns.cc | 8 ++++----
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc
> > index bea04992160..686a10caec1 100644
> > --- a/gcc/tree-vect-patterns.cc
> > +++ b/gcc/tree-vect-patterns.cc
> > @@ -3046,17 +3046,17 @@ vect_synth_mult_by_constant (vec_info *vinfo, tree op, tree val,
> >       can synthesize shifts that way.  */
> >    bool synth_shift_p = !vect_supportable_shift (vinfo, LSHIFT_EXPR, multtype);
> >  
> > +  tree vectype = get_vectype_for_scalar_type (vinfo, multtype);
> >    HOST_WIDE_INT hwval = tree_to_shwi (val);
> >    /* Use MAX_COST here as we don't want to limit the sequence on rtx costs.
> >       The vectorizer's benefit analysis will decide whether it's beneficial
> >       to do this.  */
> > -  bool possible = choose_mult_variant (mode, hwval, &alg,
> > -					&variant, MAX_COST);
> > +  bool possible = choose_mult_variant (VECTOR_MODE_P (TYPE_MODE (vectype))
> > +				       ? TYPE_MODE (vectype) : mode,
> > +				       hwval, &alg, &variant, MAX_COST);
> >    if (!possible)
> >      return NULL;
> >  
> > -  tree vectype = get_vectype_for_scalar_type (vinfo, multtype);
> > -
> >    if (!vectype
> >        || !target_supports_mult_synth_alg (&alg, variant,
> >  					   vectype, synth_shift_p))
> 
> The !vectype early out needs to move with the assignment.
> LGTM otherwise.

Whoops yes - missed that.  Will push after that fixed.

Richard.