https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641
--- Comment #21 from rguenther at suse dot de <rguenther at suse dot de> --- On Sat, 22 Jan 2022, roger at nextmovesoftware dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641 > > --- Comment #20 from Roger Sayle <roger at nextmovesoftware dot com> --- > IMHO, the problem is in tree-vect-patterns.cc's vect_synth_mult_by_constant. > The comment above line 3054 reads: > /* 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); > > By using MAX_COST here, synth_mult is being allowed to take an unbounded > amount of time, considering all possible permutations/implementations to > find an optimal synthetic multiply sequence. A more pragmatic bound might > be to compare the target's vector_multiply cost, or failing that use an > arbitrary, but reasonable limit, say COSTS_N_INSNS(8) machine instructions. > In the worst case, if it takes 100 instructions to do a vector multiply, > then the loop probably shouldn't be vectorized. Is there a way to switch synth_mult to number of insn based costs? Like using -Os metrics? And would that improve things here? I agree that an ubound search is bad but as the comment explains we want to delay costing to the vectorizer cost evaluation time ... But sure, setting an upper bound to limit compile-time sounds still reasonable.
