On Tue, Nov 4, 2025 at 9:23 AM Robin Dapp <[email protected]> wrote: > > > 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.
direct_internal_fn_supported_p (FN, type0, type1, ..) should work here, no? > 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 ;) It's more a design constraint that direct optab IFNs should be supported when in the IL. Richard, > > -- > Regards > Robin >
