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? [1] https://inbox.sourceware.org/gcc-patches/CAFiYyc3wE=xdkrzuvf1kttdrkvaaw-dyw+ztryc1p6+6nmt...@mail.gmail.com/
