https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99544

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #2)
> I think this is another case that the PR98287 proposed patch would fix,
> again after vec lowering some pass (seems vrp2 in this case), this time it
> is the
> /* Canonicalize X + (X << C) into X * (1 + (1 << C)) and
>    (X << C1) + (X << C2) into X * ((1 << C1) + (1 << C2)).  */
> match.pd rule, where the target apparently supports V2DImode left shift by
> scalar constant and addition, but doesn't support V2DImode multiplication.
> Maybe in this particular case it would be worth guarding the pattern on
> existing optab for vector multiplication or disable it for vectors
> altogether (apparently it was myself who has added that), because at least
> if the target doesn't have particular vector multiplications, I'd say doing
> the additions and shifts must be better than scalarizing it.  If
> multiplications are supported, I guess best would be to let the expansion
> decide what is better, it has code to turn scalar multiplications by
> constant into additions and shifts, so perhaps could use that also for
> vector by uniform constants?

I think in general we should be careful with patterns for vector operations
since vector expressions tend to be "optimized" (by the user or by the
compiler).

In particular even before lvec in case the source expression is supported
by the target it's not good to turn it into sth unsupported.

Basic +- arithmetic and bitwise ops are usually fine since target support is
wide-spread but I'd argue against enabling more fancy cases (integer
mult/division, shifts) without vector support checks.

What is clear is that there's no convenient helper like
direct_internal_fn_supported_p for tree codes, we should aim at providing that
(see vectorizable_shift on how awkward this can be).

So in this particular case I suggest to disable the patter for vectors
(with a comment) and work on a way to guard it appropriately without
too much boiler-plate.

Reply via email to