> Why does the expander not have a fallback here? If we put up > restrictions like this like we do for vector operations (after > vector lowering!), we need to document this. Your check covers > more than just FP16 types as well which I think is undesirable.
I'm not sure I follow. What would we fall back to if (_Float16)a + (_Float16)b is not supported? Should I provide a (_Float16)((float)a + (float)b) fallback? But that would just undo the simplification we performed. Or do you mean in optabs already? > So it seems for FP16 we need this for correctness (to not ICE) > while for other modes it might be appropriate for performance > (though I cannot imagine a target supporting say long double > not supporting float). What about something like: - && target_supports_op_p (newtype, op, optab_default) + && (!target_supports_op_p (itype, op, optab_default) + || element_mode (newtype) != HFmode + || target_supports_op_p (newtype, op, optab_default)) ? Regards Robin
