This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Meta-description for tree and gimple folding


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]