https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115427
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 11 Jun 2024, linkw at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115427 > > --- Comment #3 from Kewen Lin <linkw at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #2) > > The canonical way would be to handle these in the ISEL pass and remove > > the (fallback) expansion. But then we can see whether the expander FAILs > > (ideally expanders would never be allowed to FAIL, and for FAILing expanders > > we'd have a way to query the target like we have the vec_perm_const hook). > > > > But I'll note that currently the expanders may FAIL but then we expand to > > a call rather than the inline-expansion (and for example AVR relies on this > > now to avoid early folding of isnan). > > > > So - for the cases of isfininte and friends without a fallback call I > > would suggest to expand from ISEL to see if it FAILs and throw away > > the result (similar as how IVOPTs probes things). Or make those _not_ > > allowed to FAIL? Why would they fail to expand anyway? > > Thanks for the suggestion! IIUC considering the AVR example we still want > *isinf* to fall back with the library call (so not falling back with > inline-expansion way then). Currently at least for rs6000 port there is no > case that we want to make it FAIL, but not sure some other targets will have > such need in future. From the review comment[1], we don't note it's not > allowed to FAIL so we probably need to ensure there is some handling for FAIL > in case some future FAIL cause some unexpected failure. Do you prefer not > allowing it to FAIL? then re-open this and go with ISEL if some port wants it > to FAIL? I think it would be cleaner to not allow it FAIL since there's no library fallback. FAILing patterns are a hassle when it comes to GIMPLE optimizations. As said, there should be a good reason why patterns FAIL - what's the idea behind this feature anyway?
