https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115427
--- Comment #5 from Kewen Lin <linkw at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #4) > 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. Fair enough! > FAILing patterns are a hassle when it comes to GIMPLE > optimizations. Yeah, for some cases port isn't able to put some condition as part of condition HAVE_* (such as further checking operand special values etc.), FAIL has to be used. > > As said, there should be a good reason why patterns FAIL - what's > the idea behind this feature anyway? No solid input for this, as the proposed documentation implicitly indicates FAIL is possible to be used (like some other existing expanders), I didn't consider carefully if it has a good reason, but just assuming it can happen. :( It's a really good question if there will be a need for it.
