> 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?
Hmm yes, I guess. Normally we have gcc_checking_assert (info.type0 == info.type1); for binops but I can introduce a new IFN type "shift" that doesn't do that. We would still need to try both variants at the caller then, rather than just one but I guess we can live with that. I'll try that. >> 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. OK. -- Regards Robin
