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: Jeff Law <law at redhat dot com>
- Cc: Kai Tietz <ktietz70 at googlemail dot com>, Diego Novillo <dnovillo at google dot com>, gcc <gcc at gcc dot gnu dot org>, bilbotheelffriend at gmail dot com
- Date: Fri, 25 Apr 2014 10:54:57 +0200 (CEST)
- 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> <53598452 dot 2030305 at redhat dot com>
On Thu, 24 Apr 2014, Jeff Law wrote:
> On 02/28/14 08:21, Kai Tietz wrote:
> > Hmm, this all reminds me about the approach Andrew Pinski and I came
> > up with two years ago. 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.
> > 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.
> This is the core of what I want to see happening. I'm open to whatever
> methods we use to take us in that direction.
> The way I tend to think leads me to a "hmm, fold-const.c does X, move it to
> gimple" and iterate approach. But again, that's just the way I tend to look
> at problems.
> If we can describe significant hunks of folding using a pattern selection
> language and generate code to recognize and transform the IL, then that seems
> good to me as long as we keep the goal of moving most folding out of the
> So if Richi and GSOC students want to experiment in this space, possibly
> baking off with other approaches that delay folding, that's fine with me.
Btw, while there is the possibility to generate GENERIC foldings from
the meta-description for each and every pattern and use that from fold
it is not necessary to do that.
Note that the work also includes adding API that gets rid of most
(if not all) [fold_]buildN and force_gimple_operand_* calls from
GIMPLE passes (thus, not building GENERIC - just for the ability
to fold it - and then gimplifying it). Instead of
tree x = fold_build2 (PLUS_EXPR, type, y, build_int_cst (type, 1));
tree ex = fold_build2 (EQ_EXPR, boolean_type_node, x, y);
ex = force_gimple_operand (ex, &stmts, true, NULL_TREE);
tree x = gimple_build (&stmts, PLUS_EXPR, type, y, build_int_cst (type, 1));
tree ex = gimple_build (&stmts, EQ_EXPR, boolean_type_node, x, y);
where the implementation on the branch (obviously) relies on the
patterns to simplify the built expressions.
This should also help Andrew with his GIMPLE type re-org as it frees
him from touching fold ... (well, if all code is properly converted).
It of course remains to be seen if we can reasonably translate the
main part of the foldings passes rely on to the pattern representation.
Nothing prevents us from providing a "tail" of manually written
simplifications of course, used by the same API, but I'd like to
I hope that for 4.10 we get up to the point of using the machinery
for a gimple-combine pass (currently tree forwprop) and stop adding
simplifications to forwprop and instead extend the pattern description.
I also hope to convert most passes over to gimple_build (requires
mostly simple arithmetic simplification and simplification of
Comments on the actual code are always welcome - we'll do
all the GSOC project discussions on implementation details in
public to invite others to comment.