This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Meta-description for tree and gimple folding
- From: Richard Biener <rguenther at suse dot de>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 12 Mar 2014 10:02:22 +0100 (CET)
- Subject: Re: [RFC] Meta-description for tree and gimple folding
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1402271509470 dot 27942 at zhemvz dot fhfr dot qr> <alpine dot DEB dot 2 dot 10 dot 1402280938290 dot 3586 at laptop-mg dot saclay dot inria dot fr> <alpine dot LSU dot 2 dot 11 dot 1403031150210 dot 11121 at zhemvz dot fhfr dot qr> <alpine dot DEB dot 2 dot 10 dot 1403112215160 dot 3618 at laptop-mg dot saclay dot inria dot fr>
On Tue, 11 Mar 2014, Marc Glisse wrote:
> On Mon, 3 Mar 2014, Richard Biener wrote:
>
> > > How do you handle a
> > > transformation that currently tries to recursively fold something else and
> > > does the main transformation only if that simplified?
> >
> > And doesn't do the other folding (because it's not in the IL literally?)?
> > Similar to the cst without overflow case, by writing custom C code
> > and allowing that to signal failure.
>
> Note that for this kind of simplification, it can be inconvenient to have
> canonicalization included with the "real" simplifications. Imagine I am
> looking at (x?3:5)+y. If 3+y "simplifies" to y+3 and 5+y "simplifies" to y+5,
> then it looks worth it to replace the expression with x?y+3:(y+5).
>
> Would there be a convenient way to separate them, so it can tell me that 3+y
> should be replaced with y+3 but that it is not a simplification?
You could certainly "mark" those patterns in a special way (though
the specific case, 3 + y to y + 3 will happen behind patterns back,
so in this case it won't tell you that 3 + y simplifies). Note that
you can't write patterns that apply "if 3 + y simplifies", at
least not without doing sth as awkward as
(match_and_simplify
(plus (cond @0 @1 @2) @3)
if (gimple_match_and_simplify (PLUS_EXPR, TREE_TYPE (@1), @1, @3, NULL,
NULL)
|| gimple_match_and_simplify (PLUS_EXPR, TREE_TYPE (@2), @2, @3,
NULL, NULL))
(cond @0 (plus @1 @3) (plus @2 @3)))
that is, very much do extra work. We'd maybe want to be able to
instead write
(match_and_simplify
(plus (cond @0 @1 @2) @3)
(cond @0 (plus:simplifies_p @1 @3) (plus:simplifies_p @2 @3)))
but I'm not sure how to best express whether both expressions have to
simplify or only one ... (eventually only allow || here, as we
should commit to use a simplification once we created it, not throw
it away eventually). Or sth like
(match_and_simplify
(plus (cond @0 @1 @2) @3)
if simplifies (plus@4 @1 @3)
(cond @0 @4 (plus @2 @3))
not sure how to do || vs. && (or even two simplifies conditions) best.
OTOH, I'd rather avoid adding those kind of patterns for now. There
are interesting enough challenges with existing "simple" ones.
Richard.