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.
