Oops, now also to the list.
On Tue, 2 Sep 2025, Richard Biener wrote: > On Tue, 2 Sep 2025, Jakub Jelinek wrote: > > > On Tue, Sep 02, 2025 at 10:36:52AM +0200, Richard Biener wrote: > > > The recent change to vect_synth_mult_by_constant missed to handle > > > the synth_shift_p case for alg_shift, so we still changed c * 4 > > > to c + c + c + c. > > > > The reason for not handling alg_shift was that it expands (perhaps multiple > > times) the accumulator rather than op. > > Though, if alg[0] sets accumulator to op, then it does that, accumulator > > is op. > > > > I guess the question is, what exactly is problematic wrt the multiple uses, > > I understand > > _1 = op + op; > > _2 = _1 + op; > > _3 = _2 + op; > > is wrong, but what about > > _1 = op; > > _2 = _1 + _1; > > _3 = _2 + _2; > > ? > > That's also wrong, what the requirement actually is is that there's > a single-use chain from the loop latch def to the PHI result. Here > you have _2 + _2 so two edges. > > I think patterns like this that turn one stmt into multiple ones > shouldn't be done as patterns. Instead vectorizable_operation > should simply emit (and earlier cost) a sequence of vector stmts. > It could be done as a new vectorizable_synth_mult for example. > I know it's convenient the way it's done, but I can't see that > it's much more ugly when done late. > > Note there's nothing wrong in principle with a reduction with > open-coded multiplication, it's just the reduction code isn't > prepared for this kind of SSA cycle. > > > The reduction is then used just once (unless something optimizes it) and > > only the temporaries are perhaps used multiple times. > > If this is ok, perhaps instead of giving up we could simply force > > op into a new SSA_NAME and use that in the code instead of the original > > op. > > If it is not and we can't use any temporaries multiple times, then perhaps > > the current code is incorrect in more ways. > > Yes, that's what I was trying to fix (we now ICE with an assert > instead of failing vectorization later, because a graceful fail > wasn't easily possible - thinking of, maybe it is actually > possible). > > Richard. > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
