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]

Re: [gsoc 2014] moving fold-const patterns to gimple


On Sun, Mar 2, 2014 at 9:13 PM, Prathamesh Kulkarni
<bilbotheelffriend@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


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