On Sun, Mar 2, 2014 at 9:13 PM, Prathamesh Kulkarni <bilbotheelffri...@gmail.com> wrote: > Hi, I am an undergraduate student at University of Pune, India, and would > like to work on moving folding patterns from fold-const.c to gimple.
I've seen the entry on our GSoC project page and edited it to discourage people from working on that line. See http://gcc.gnu.org/ml/gcc/2014-02/msg00516.html for why. I think that open-coding the transforms isn't maintainable in the long run. > If I understand correctly, constant folding is done on GENERIC (by > routines in fold-const.c), and then GENERIC is lowered to GIMPLE. The > purpose of this project, > is to have constant folding to be performed on GIMPLE instead (in > gimple-fold.c?) > > I have a few elementary questions to ask: > > a) A contrived example: > Consider a C expression, a = ~0 (assume a is int) > In GENERIC, this would roughly be represented as: > modify_expr<var_decl "a", <bit_not_expr<integer_cst 0>>> > this gets folded to: > modify_expr<var_decl "a", integer_cst -1> > and the corresponding gimple tuple generated is (-fdump-tree-gimple-raw): > gimple_assign <integer_cst, x, -1, NULL, NULL> > > So, instead of folding performed on GENERIC, it should be > done on GIMPLE. > So a tuple like the following should be generated by gimplification: > <bit_not_expr, a, 0, NULL, NULL> > and folded to (by call to fold_stmt): > <integer_cst, a, -1, NUL, NULL> > Is this the expected behavior ? > > I have attached a rough/incomplete patch (only stage1 compiled cc1), that > does the following foldings on bit_not_expr: > a) ~ INTEGER_CST => folded > b) ~~x => x > c) ~(-x) => x - 1 > (For the moment, I put case BIT_NOT_EXPR: return NULL_TREE > in fold_unary_loc to avoid folding in GENERIC on bit_not_expr) > > Is the patch going in the correct direction ? Or have I completely missed > the point here ? I would be grateful to receive suggestions, and start working > on a fair patch. I think you implement what was suggested by Kai (and previously by me and Andrew, before I changed my mind). Richard. > On the following test-case: > int main() > { > int a, b, c; > a = ~~~~b; > c = ~-a; > return 0; > } > > The following GIMPLE is generated: > main () > gimple_bind < > int D.1748; > int D.1749; > int D.1750; > int D.1751; > int D.1752; > int a; > int b; > int c; > > gimple_assign <var_decl, D.1749, b, NULL, NULL> > gimple_assign <var_decl, a, D.1749, NULL, NULL> > gimple_assign <plus_expr, c, a, -1, NULL> > gimple_assign <integer_cst, D.1752, 0, NULL, NULL> > gimple_return <D.1752> >> > > The patch generates two tuples for a = ~~~~b, > where only one is needed, and extra temporaries, which > are not removed after the folding. How should I go about > removing that (should I worry about that since subsequent passes, > shall remove those ?) > > b) Some front-ends, C, for example, requires constant folding in certain > places, > like case statement. If constant folding is completely moved off to gimple, > how shall this be handled ? Shall we gimplify the expression immediately if > it's required to be evaluated ? > > Thanks and Regards, > Prathamesh
