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

[Richard Biener <rguenther@suse.de>]

On Tue, 27 Jun 2023, Robin Dapp wrote:

> > 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?

Yeah, the optab should already have the fallback of WIDENing here?
So why does that fail?

> > 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))

I'd say

      && (!target_supports_op_p (itype, op, optab_default)
          || target_supports_op_p (newtype, op, optab_default))

would make sense in general.  But as said you'll likely find (many?)
other places affected.  Singling out HFmode probably doesn't work
across targets since this mode isn't defined in generic code.

Richard.