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.
