Re: [PATCH] match.pd: Use element_mode instead of TYPE_MODE.

[Robin Dapp <rdapp.gcc@gmail.com>]

> 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