This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Minimize downward code motion during reassociation
- From: Easwaran Raman <eraman at google dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org, aoliva at gcc dot gnu dot org
- Date: Wed, 24 Apr 2013 16:03:22 -0700
- 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>
I want to resend this patch for consideration. I applied the patch to
trunk and confirmed that it bootstraps and doesn't cause test
regressions. Is this ok for trunk?
Thanks,
Easwaran
On Fri, Dec 7, 2012 at 12:01 PM, Easwaran Raman <eraman@google.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?
>
> Thanks,
> Easwaran
>
> 2012-12-07 Easwaran Raman <eraman@google.com>
> * 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
> <richard.guenther@gmail.com> wrote:
>> On Tue, Nov 6, 2012 at 1:54 AM, Easwaran Raman <eraman@google.com> 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.
>>
>> Richard.