On Thu, 27 Feb 2014, Richard Biener wrote:
I've been hacking on a prototype that generates matching and simplification code from a meta-description. The goal is to provide a single source of transforms currently spread over the compiler, mostly fold-const.c, gimple-fold.c and tree-ssa-forwprop.c. Another goal is to make these transforms (which are most of the form of generating a simpler form of a pattern-matched IL piece) more readily available to passes like value-numbering so they can be used on-the-fly, using information provided by the pass lattice. The ultimate goal is to generate (most of) fold-const.c and gimple-fold.c and tree-ssa-forwprop.c from a single meta description.
[...]
Comments or suggestions?
It is hard to judge from such simple examples. What if I want to do the transformation only if CST+CST' doesn't overflow? Can I make it handle commutative operations cleverly? How do I restrict some subexpression to have a single use? If I want to check some flag_*, do I have to create a predicate that tests for that as well as whatever other test the specific operand needed? Won't valueize create a lot of not-so-necessary trees when used on gimple? If I write a COND_EXPR matcher, could it generate code for phiopt as well? What is the point of gimple_match (without _and_substitute)? Will it clean up the new dead statements after itself? Can I write (PLUS_EXPR@0 @1 @2) so I can still refer to this subexpression later? How do you handle a transformation that currently tries to recursively fold something else and does the main transformation only if that simplified?
I guess most of the answers will become obvious once you have converted a few existing transformations and I can look at those...
Since this is going to require a rewrite of many transformations, I wonder if there are things that should be improved before starting so we can write the right tests directly. For A+B-B, we can do the transformation if the type is an integer for which overflow either wraps or is undefined or traps-but-it-is-ok-to-remove-those-traps (but not if it traps and we promise to preserve traps, or if the type saturates), or the type is a float and we have the unsafe math flag, or the type is a vector/complex and the transformation is valid for the element type. Ok, maybe not the best example, but we have for instance -ftrapping-math for which a split was discussed (PR 53805#c4).
-- Marc Glisse
