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)
Richard.
> --
> Marc Glisse
