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.
