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 is bad). > 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)? Thanks, Richard.
