Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > On Thu, Jul 23, 2020 at 11:11 AM Marc Glisse <marc.gli...@inria.fr> wrote: >> >> On Thu, 23 Jul 2020, Marc Glisse wrote: >> >> > On Wed, 22 Jul 2020, Roger Sayle wrote: >> > >> >> Many thanks for the peer review and feedback. I completely agree that >> >> POPCOUNT >> >> and PARITY iterators simplifies things and handle the IFN_ variants. >> > >> > Is there a reason why the iterators cannot be used for this one? >> > >> > +(for popcount (BUILT_IN_POPCOUNT BUILT_IN_POPCOUNTL BUILT_IN_POPCOUNTLL >> > + BUILT_IN_POPCOUNTIMAX) >> > + parity (BUILT_IN_PARITY BUILT_IN_PARITYL BUILT_IN_PARITYLL >> > + BUILT_IN_PARITYIMAX) >> > + (simplify >> > + (bit_and (popcount @0) integer_onep) >> > + (parity @0))) >> >> Ah, maybe because we may have platforms/modes where the optab for popcount >> is supported but not the one for parity, and we are not allowed to create >> internal calls if the optab is not supported? I think expand_parity tries >> to expand parity as popcount&1, so it should be fine, but I didn't >> actually try it... > > Hmm, that might indeed be a problem. An explicit > direct_internal_fn_supported_p guard would help here, like > maybe > > (if (PARITY != IFN_PARITY > || direct_internal_fn_supported_p (IFN_PARITY, type, > OPTIMIZE_FOR_BOTH)) > (PARITY @0))) > > magic that eventually could be auto-generated by genmatch ... (but only if > iterating, so it would be a bit iffy)
The matching code should already reject folds to IFN_PARITY calls that aren't supported by the target (gimple-match-head.c:build_call_internal). Thanks, Richard
