Hi, Unfortunately I shall need to take this week off, due to university exams, which are up-to 27th May. I will start working from 28th on pattern matching with decision tree, and try to cover up for the first week. I am extremely sorry about this. I thought I would be able to do both during exam week, but the exam load has become too much -:(
In the first phase (up-to 23rd June), I hope to get genmatch ready: a) pattern matching with decision tree. b) Add patterns to test genmatch. c) Depending upon the patterns, extending the meta-description d) Other fixes: * capturing outermost expressions. For example this pattern does not get simplified (match_and_simplify (plus@2 (negate @0) @1) if (!TYPE_SATURATING (TREE_TYPE (@2))) (minus @1 @0)) I guess this happens because in write_nary_simplifiers: if (s->match->type != OP_EXPR) continue; Maybe this is not correct way to fix this, should we also pass lhs to generated gimple_match_and_simplify ? I guess that would be the capture for outermost expression. For above pattern, I guess @2 represents lhs. So for this test-case: int foo (int x, int y) { int t1 = -x; int t2 = t1 + y; return t2; } t2 would be @2, t1 would be @0 and y would be @1. Is that correct ? This would create issues when lhs is NULL, for example, in call to built-in functions ? * avoid using statement expressions for code gen of expression * rewriting code-generator using visitor classes, and other refactoring (using std::string for example), etc. I have a very rough time-line in mind, for completing tasks: 28th may - 31st may a) Have test-case for each pattern present (except COND_EXPR) in match.pd I guess most of it is already done, a few patterns are remaining. b) Small fixes (for example, those mentioned above). c) Have an initial idea/prototype for implementing decision tree 1st June - 15th June a) Implementing decision tree b) Adding patterns in match.pd to test the decision tree in match.pd, and accompanying test-cases in tree-ssa/match-*.c 16th June - 23rd June a) Support for GENERIC code generation. b) Refactoring and backup time for backlog. GENERIC code generation: I am a bit confused about this. Currently, pattern matching is implemented for GENERIC. However I believe simplification is done on GIMPLE. For example: (match_and_simplify (plus (negate @0) @1) (minus @0 @1)) If given input is GENERIC , it would do matching on GENERIC, but shall transform (minus @0 @1) to it's GIMPLE equivalent. Is that correct ? * Should we have a separate GENERIC match-and-simplify API like for gimple instead of having GENERIC matching in gimple_match_and_simplify ? * Do we add another pattern type, something like generic_match_and_simplify that will do the transform on GENERIC for example: (generic_match_and_simplify (plus (negate @0) @1) (minus @0 @1)) would produce GENERIC equivalent of (minus @0 @1). or maybe keep match_and_simplify, and tell the transform operand to produce GENERIC. Something like: (match_and_simplify (plus (negate @0) @1) GENERIC: (minus @0 @1)) Another thing I would like to do in first phase is figure out dependencies of tree-ssa-forwprop on GENERIC folding (for instance fold_comparison patterns). Thanks and Regards, Prathamesh