[RFC] Meta-description for tree and gimple folding

[Richard Biener]

On Wed, 12 Mar 2014, Marc Glisse wrote:

> On Wed, 12 Mar 2014, Richard Biener wrote:
> 
> > 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).
> 
> Ah, that's good, maybe what I was asking for is mostly already there :-)
> 
> > 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)))
> 
> I think it's ok having to write something a bit longer when doing complicated
> things, as long as it is doable at all.
> 
> > that is, very much do extra work.
> 
> Ah, because the simplification of each PLUS_EXPR will be done twice?

Yes.

> > OTOH, I'd rather avoid adding those kind of patterns for now.  There
> > are interesting enough challenges with existing "simple" ones.
> 
> Sure.