This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Meta-description for tree and gimple folding
- From: Richard Biener <rguenther at suse dot de>
- To: Diego Novillo <dnovillo at google dot com>
- Cc: gcc <gcc at gcc dot gnu dot org>
- Date: Mon, 3 Mar 2014 12:25:43 +0100 (CET)
- Subject: Re: [RFC] Meta-description for tree and gimple folding
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1402271509470 dot 27942 at zhemvz dot fhfr dot qr> <CAD_=9DRLz1HSCMbhDL4HW8stJVGX9nxZyBZybg6LbRUOf63YcQ at mail dot gmail dot com>
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.