On Fri, 28 Feb 2014, Diego Novillo wrote: > On Thu, Feb 27, 2014 at 9:34 AM, Richard Biener <rguent...@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.