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?
OTOH, I'd rather avoid adding those kind of patterns for now. There
are interesting enough challenges with existing "simple" ones.
Sure.
--
Marc Glisse
