On Tue, 27 Jun 2023, Robin Dapp wrote: > > Can you push the element_mode change separately please? > > OK. > > > I'd like to hear more reasoning of why target_supports_op_p is wanted > > here. Doesn't target_supports_op_p return false if this is for example > > a soft-fp target? So if at all, shouldn't the test only be carried > > out if the original operation was supported by the target? > > Tamar and I discussed whether a target check is appropriate yesterday > already here and were torn. How or where would we expect a non-supported > operation to be discarded, though? In my case the expression is generated > during a ranger fold and survives until expand where we ICE.
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. 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). Richard.
