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

[Richard Biener <rguenther at suse dot de>]

On Fri, 28 Feb 2014, Diego Novillo wrote:

> On Thu, Feb 27, 2014 at 9:34 AM, Richard Biener <rguenther@suse.de> wrote:
> 
> > Comments or suggestions?
> 
> On the surface it looks like a nice idea.  However, I would like to
> understand the scope of this.  Are you thinking of a pattern matcher
> with peephole like actions?  Or would you like to evolve a DSL capable
> of writing compiler passes?  (much like MELT).
> 
> I prefer keeping it simple and limit the scope to pattern matching and
> replacement. There will be other things to handle, however (overflow,
> trapping arithmetic, etc).  The language will grow over time.
> 
> In terms of the mini-language, I don't like the lisp syntax but I
> appreciate that it is a familiar language for GCC since the backend
> uses it extensively.
> 
> Please consider testing facilities as well. We should be able to write
> unit tests in this language to test its syntax validation, semantic
> actions, and transformations.

Ok, so let me summarize some of the goals which should answer most
of the questions above.

 1) The IL matching should be translatable to a state machine
   so it becomes O(1) and not O(number of patterns).  [so we
   should be able to move to "mandatory folding" on stmt
   changes in GIMPLE, similar to how we've done it with
   requiring you to use fold_buildN instead of buildN.
   Currently that has a very high cost because we re-build
   GENERIC on folding GIMPLE and dispatch to fold-const.c] 
 2) The generator should be able to target both GENERIC and
   GIMPLE so we can "move" things from fold-const.c to GIMPLE
   ("move" as in add it to GIMPLE but leave it in fold-const.c
   to not regress frontend dependences on it).
 3) The whole thing should enable transitioning away from
   using force_gimple_operand (fold_buildN (....)) by providing
   the GIMPLE equivalent of fold_buildN.  [less trees in the
   middle-end]
 4) The API to the match-and-simplify routine should allow
   (SSA) propagators to use the routine for simplifying
   stmts with their current lattice value (CCP, DOM and
   SCCVN are the obvious candidates here).

So yes, because of 1) the matching part will be similar to
how the machine description handles insns.  The actual
transform can be more complex (and I expect it so, see my
reply to Marc).

I expect the language to grow over the existing proposal
but not so much over time (at least I hope so - heh).

As of testing facilities ... I don't see how I can use
the language to write tests?  Do you think of sth like
(very simplified)

/* Match and simplify CST + CST to CST'.  */
(define_match_and_simplify baz
  (PLUS_EXPR INTEGER_CST_P@0 INTEGER_CST_P@1)
  { int_const_binop (PLUS_EXPR, captures[0], captures[1]); })

(test baz
  (PLUS_EXPR 1 2)
  3)

?

Thanks,
Richard.