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.
Jeff
