This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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
> front-ends.
> 
> 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);

you do

 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
avoid that.

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
conditionals).

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.

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]