This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
[GSoC] first phase
- From: Prathamesh Kulkarni <bilbotheelffriend at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, Diego Novillo <dnovillo at google dot com>, Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>, gcc <gcc at gcc dot gnu dot org>
- Date: Mon, 19 May 2014 23:00:40 +0530
- Subject: [GSoC] first phase
- Authentication-results: sourceware.org; auth=none
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