On Mon, 3 Nov 2025, Avinash Jayakar wrote:
> On Fri, 2025-10-24 at 16:21 +0530, Avinash Jayakar wrote:
> > Hi,
> >
> > I have incorporated the changes suggested in the previous version.
> > For now the
> > bare bones version of multiply by constant pattern recog is
> > implemented in
> > tree-vect-generic.cc, which should help fixing the failing test cases
> > in 119702.
> >
> > But to fix PR122065, will need to implement the lowering as done in
> > tree-vect-patterns.cc, which I can do in a separate patch.
> >
> Hi Richard,
>
> Currently this issue has been fixed for when the constant scenarios
> such as:
> vector_a = vector_b * { c1, c2...}
> where c1, c2 ... are perfect power of 2 and are positive.
>
> For a more generic case, where adds or subs along with shifts are
> required, we need to do a similar thing that is done in tree-vect-
> patterns.cc, where the function vect_synth_mult_by_constant uses
> choose_mult_variant function to come up with which variant of algorithm
> to use.
>
> One main challenge of using that here is on how to determine the max
> cost of MULT_EXPR. In patterns, MAX_INT is used because the benefit
> analyzer would compare the scalar vs vector cost. In expmed.cc,
> set_src_cost is used.
> But such things are not possible in tree-vect-generic.cc, so
> Is it recommended to implement the cases where constants are not power
> of 2. If so, what would be the max_cost parameter for the function
> choose_mult_variant?
I'd say a reasonable lower bound would be N times the component scalar
multiplication cost. It's not really possible to do a good estimation
of the vector extraction/build costs since the lowering happens per
stmt, so accumulation of that cost across a chain of stmts isn't
estimated.
Richard.
> Thanks and regards,
> Avinash Jayakar
>
--
Richard Biener <[email protected]>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
