This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[GSoC] first phase


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]