This is the mail archive of the
mailing list for the GCC project.
Re: Minimize downward code motion during reassociation
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Easwaran Raman <eraman at google dot com>
- Cc: gcc-patches at gcc dot gnu dot org, aoliva at gcc dot gnu dot org
- Date: Thu, 25 Apr 2013 13:42:06 +0200
- Subject: Re: Minimize downward code motion during reassociation
- References: <CAPK5YPYUsvoskSJTfqYn+FPyTY0qQqzSJQ05B4dAzt0oefn-Ug at mail dot gmail dot com> <CAFiYyc3OpkXDo_WbMAsAoYgwfL4q7fxVF4rmAiDOT=omA9k=GA at mail dot gmail dot com> <CAPK5YPb0f0BJ3Z_MTSuJ0_Gw6bsRETbM0yNs_W6VC8sB58Edig at mail dot gmail dot com> <CAFiYyc3KEsyNeLK25F+k72LiD+mE=WW1SDxD4msX38OoSf_sMA at mail dot gmail dot com> <CAPK5YPYPYoDK2f-LcRvmt+JrCEiuM-yAQrv=ecYGcCAGv0VS6w at mail dot gmail dot com> <CAFiYyc0-JKh07Dn37WO7z3coz1-fHDU17+cDqV=kWCQi7v3uFQ at mail dot gmail dot com> <CAPK5YPbabJ+2ZgjK3O2nqFdXkUBnD-1n5DaEJU8T7+=oiayn=g at mail dot gmail dot com> <CAFiYyc2OvKGkPH5xcsQv14ECww6nm8gOe9V=+XAFTD=FBkSZ5A at mail dot gmail dot com> <CAPK5YPZb5Wb2D0AW-VuT_A4hQoUTwm7kk1nVoYpTftE1JVOLJg at mail dot gmail dot com> <CAFiYyc1tqX9p-ddesbCNPOBM6hQKbe6NZFK=TR6wjxRKYsjO1A at mail dot gmail dot com> <CAPK5YPZ7J1AvPhPdpQYtoZLeFJXjEfpT8-TuDROjHdioFB2iHQ at mail dot gmail dot com>
On Fri, Dec 7, 2012 at 9:01 PM, Easwaran Raman <email@example.com> wrote:
> It seems I need to reset the debug uses of a statement before moving
> the statement itself. The attached patch starts from the leaf to root
> of the tree to be reassociated and places them at the point where
> their dependences will be met after reassociation. This bootstraps and
> I am running the tests. Ok if there are no test failures?
+ if ((dep_bb != insert_bb
+ && !dominated_by_p (CDI_DOMINATORS, insert_bb, dep_bb))
+ || (dep_bb == insert_bb
+ && gimple_uid (insert_stmt) < gimple_uid (dep_stmt)))
+ insert_stmt = dep_stmt;
+ /* If there are any debug uses of LHS, reset them. */
+ FOR_EACH_IMM_USE_STMT (use_stmt, iter, lhs)
+ if (is_gimple_debug (use_stmt))
+ gimple_debug_bind_reset_value (use_stmt);
that's only needed for debug stmts that are not dominated by insert_point, no?
+ /* Statements marked for throw can not be in the middle of a basic block. So
+ we can not insert a statement (not marked for throw) immediately
+ else if (stmt_can_throw_internal (insert_point))
use stmt_ends_bb_p (insert_point) instead
+ edge succ_edge = find_fallthru_edge (insert_bb->succs);
+ insert_bb = succ_edge->dest;
+ /* Insert STMT at the beginning of the successor basic block. */
+ gsi_insert = gsi_after_labels (insert_bb);
+ gsi_move_before (&gsistmt, &gsi_insert);
are you sure this is a proper insert location? How would you even arrive in
this situation given find_insert_point dominance checks?
Otherwise the patch looks ok - can you add one or two testcases please?
> 2012-12-07 Easwaran Raman <firstname.lastname@example.org>
> * tree-ssa-reassoc.c(find_insert_point): New function.
> (insert_stmt_after): Likewise.
> (get_def_stmt): Likewise.
> (ensure_ops_are_available): Likewise.
> (rewrite_expr_tree): Do not move statements beyond what is
> necessary. Remove call to swap_ops_for_binary_stmt...
> (reassociate_bb): ... and move it here.
> (build_and_add_sum): Assign UIDs for new statements.
> (linearize_expr): Likewise.
> (do_reassoc): Renumber gimple statement UIDs.
> On Thu, Dec 6, 2012 at 1:10 AM, Richard Biener
> <email@example.com> wrote:
>> On Tue, Nov 6, 2012 at 1:54 AM, Easwaran Raman <firstname.lastname@example.org> wrote:
>>> I am unable to figure out the right way to handle the debug
>>> statements. What I tried was to find debug statements that use the SSA
>>> name defined by the statement I moved (using SSA_NAME_IMM_USE_NODE)
>>> and then moved them as well at the right place. Thus, if I have to
>>> move t1 = a + b down (after the definition of 'd'), I also moved all
>>> debug statements that use t1 after the new position of t1. That still
>>> caused use-before-def problems in ssa_verify. I noticed that the debug
>>> statements got modified behind the scenes causing these issues. Any
>>> hints on what is the right way to handle the debug statements would be
>>> very helpful.
>> I think you cannot (and should not) move debug statements. Instead you
>> have to invalidate them. Otherwise you'll introduce confusion as debug
>> info cannot handle overlapping live ranges.
>> But maybe Alex can clarify.