[RFC] Meta-description for tree and gimple folding

Marc Glisse marc.glisse@inria.fr
Wed Mar 12 09:16:00 GMT 2014


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



More information about the Gcc mailing list