On Thu, Jul 23, 2020 at 12:58 PM Richard Sandiford <richard.sandif...@arm.com> wrote: > > 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).
Ah, indeed, so it should work unchanged even. Richard. > Thanks, > Richard
