This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Meta-description for tree and gimple folding
- From: Richard Biener <rguenther at suse dot de>
- To: Kai Tietz <ktietz70 at googlemail dot com>
- Cc: Diego Novillo <dnovillo at google dot com>, gcc <gcc at gcc dot gnu dot org>
- Date: Mon, 3 Mar 2014 12:33:33 +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> <CAEwic4ZbtUr1j2XgHxf+BZ6xwsy+zcDnjcnuU2LcGq=0Ak_vow at mail dot gmail dot com>
On Fri, 28 Feb 2014, Kai Tietz wrote:
> Hmm, this all reminds me about the approach Andrew Pinski and I came
> up with two years ago.
You are talking about the gimple folding interface? Yes, but it's
more similar to what I proposed before that.
> All in all I think it might be worth to
> express folding-patterns in a more abstract way. So the md-like Lisp
> syntax for this seems to be just stringent. We make use of such a
> script-language already for machine-description.
That's the reason I use something similar. Because that form
proved useful for instruction selection and peephole-like transforms.
Exactly what you can generate a state machine for for matching
(the current serial try-fail-try-fail... processing of cases
> Nevertheless I doubt that we really want to have same facility for
> fold-const and gimple. Instead I got the impression that we would
> prefer to have all folding-optimizations instead in Middle-end
> (GIMPLE). We need folding in front-end (AST) mostly for determination
> of constant-expression detection. Otherwise we want to keep maximum of
> original AST to have best results for debugging (and even to think
> about having alternative FE on our middle/backend) and code-analyzers.
True, but it's a dead end to rely on FEs implementing their own
folding to be able to remove sth from fold-const.c. And we don't
exactly have to implement the GENERIC code generation part.
> So I doubt that we want to keep fold-const patterns similar to gimple
> (forward-prop) ones.
> Wouldn't it make more sense to move fold-const patterns completely
> into gimple, and having a facility in FE to ask gimple to *pre*-fold a
> given tree to see if a constant-expression can be achieved?
That was proposed by somebody, yes. The FE would hand off an
expression to 1) the gimplifier to gimplify it, then 2) to the
gimple folder to simplify it. Not sure if that's a good design
but yes, it mimics the awkward thing we do now (genericize for
folding in fold_stmt), just the other way around - and it makes
it very costly.
Having a single meta-description of simplifications makes it
possible to have the best of both worlds (no need to GENERICIZE
back from GIMPLE and no need to GIMPLIFY from GENERIC) with
a single point of maintainance.
[the possibility to use offline verification tools for the
transforms comes to my mind as well]
If you think the .md style pattern definitions are too limiting
can you think of sth more powerful without removing the possibility
of implementing the matching with a state machine to make it O(1)?