https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335
--- Comment #7 from rdapp at linux dot ibm.com --- Sorry for not getting back to this earlier, talked to Segher off-list about this quickly. >> The check >> >> if (FLOAT_MODE_P (compare_mode) && !FLOAT_MODE_P (result_mode)) > > With compare_mode SFmode, and result_mode, what, SImode? Or VOIDmode? > In either case this would be true. > >> fails and we return false > > Which does not match my argument assumptions then, so they must be wrong. We had compare_mode == SFmode and result_mode == DImode before, making the whole if condition false, causing return false; > But this is done during expand only, costing is pretty irrelevant there. > expand should emit correct code, and later passes optimise that. Many of our > oldest problems are expand trying to "optimise" things :-( > > Or is this function called later as well? Yes this does not happen in expand here but during if-convert. >> dest is the same as before > > Which is? dest = (reg/f:DI 122 [ bestFuzz$__object ]) >> but now we have >> >> FLOAT_MODE_P (compare_mode) == false > > That is wrong then. > >> and >> >> if (FLOAT_MODE_P (compare_mode) && !FLOAT_MODE_P (result_mode)) >> >> not causing a return false. > > So you meant that FLOAT_MODE (compare_mode) is true? The whole condition is now if (FLOAT_MODE (CCFPmode) && !FLOAT_MODE (DImode)) causing no return false. > Yes, rs6000_generate_compare does not expect the funny RTL for a condition > code as input: it wants a real comparison, instead, so not a representation > of the result of such a comparison. > Yes you are right that this is not something that is usually expected as a comparison. Maybe in the future we can find a better way of informing backends about both choices. > Hard to say, I don't find documentation for this. But, such a change is not > in scope for stage 4, no matter how you look at it :-( I agree that I should have at least updated the optab doc for this. Going to do so still. I attached a hack that just returns false whenever a CCmode compare is passed to the Power backend functions. This should get you back the behavior from before the patch. I managed to bootstrap on Power 10 with ./configure --enable-languages=all --with-cpu=power10 fwiw. The testsuite ran but I saw plenty of go FAILS. Making use of the passed "CC compare"/result is probably a little more involved but essentially it should be possible to get rid of all the preparation steps for CC generation in that case.
