> We shouldn't have created the IFN in the first palace if it isn't supported. > So I think whatever did that misses the internal-fn-supported check instead.
We do check whether the IFN is supported, it's a standard direct_optab_handler test with the proper optab and its mode. But that doesn't include the mode or non-mode of the shift-count operand. So IMHO we need a can_shift_by_imm_p (like we have for vec_extract for example) one way or another and it's just the question where. The IFN check is in supportable_widening_operation but to me it would feel a bit out of place to switch alternatives there. What we could do is decide in vect pattern recognition similar to what we do in vect_synth_mult_by_constant? I don't find the vect lowering placement terrible, though ;) -- Regards Robin
