This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: match.pd: Optimize (x & y) ^ (x | y)
- From: Richard Biener <rguenther at suse dot de>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: Marek Polacek <polacek at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 16 Jun 2015 15:45:38 +0200 (CEST)
- Subject: Re: match.pd: Optimize (x & y) ^ (x | y)
- Authentication-results: sourceware.org; auth=none
- References: <20150611110432 dot GY2756 at redhat dot com> <20150611110905 dot GW10247 at tucnak dot redhat dot com> <20150611120246 dot GZ2756 at redhat dot com> <alpine dot DEB dot 2 dot 20 dot 1506112127430 dot 1589 at laptop-mg dot saclay dot inria dot fr> <F754CE2F-C241-4380-996E-93B9EA4A03F0 at suse dot de> <alpine dot DEB dot 2 dot 20 dot 1506120834490 dot 1593 at laptop-mg dot saclay dot inria dot fr> <20150612090204 dot GF2756 at redhat dot com> <alpine dot DEB dot 2 dot 20 dot 1506131206070 dot 2373 at laptop-mg dot saclay dot inria dot fr>
On Sat, 13 Jun 2015, Marc Glisse wrote:
> On Fri, 12 Jun 2015, Marek Polacek wrote:
>
> > > > > fold-const.c traditionally avoided the combinatorial explosion by
> > > > > using
> > > > > strip_nops.
> > > >
> > > > Yeah. We can probably special case conditional conversions in code
> > > > generation instead of lowering it. And then go the full way and special
> > > > case nop conversions so you can avoid writing the predicate as well.
> > >
> > > Without special casing, I currently have:
> > >
> > > (match (nopcvt @0)
> > > (convert? @0)
> > > (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))))
> > > (simplify
> > > (bit_xor:c (convert1? (bit_and@2 (nopcvt @0) (nopcvt @1)))
> > > (convert2? (bit_ior:c (nopcvt @0) (nopcvt @1))))
> > > (if (tree_nop_conversion_p (type, TREE_TYPE (@2)))
>
> This could use @0 instead of @2 to save 2 characters.
>
> > > (bit_xor (convert @0) (convert @1))))
> > >
> > > which simplifies Jakub's testcase without exploding the size of *-match.c,
> > > but it is still not very satisfying.
> >
> > Yeah, imagine if we'd have to change every pattern like that :-(.
Indeed. I don't like adding that (match (nopcvt)). We should improve
on the IL instead.
> I am not sure that we will be able to completely avoid it. Nop conversions can
> be ignored in some places, but not everywhere, so we have to be explicit about
> it. We could make a nice short notation, say bit_and# to switch whether there
> is an implicit strip_nops or not, and pick the default that applies to most
> patterns. We would still need a way to access the unstripped version of @2
> (@#2 maybe?). And we would still need the 'convert' in the output pattern,
> unless we teach genmatch to add nop conversions in many places, which sounds
> complicated.
Yeah, I also think we want to be explicit, which means adding both
the conditional nop-convert and the output convert. What we can do
is invent new [s]nop (according to STRIP_NOPS / STRIP_SIGN_NOPS)
codes that when used conditional (not sure if we want to support
unconditional use?) always act like if you were using nop1, nop2, nop3,
... but special-case it in code-generation to magically add
a tree_nop_conversion_p check (somewhere).
I think we can't easily remove the exponential explosion in the number
of nodes in the decision tree though (but for a single leaf op or by
outlining to a function which is the effect of your (match (nopcvt))
approach - though in the end I'd like to have those "inlined")
Richard.