RE: dom requires PROP_loops
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: 13 March 2014 18:46
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: RE: dom requires PROP_loops
On March 13, 2014 5:00:53 PM CET, Paulo Matos pma...@broadcom.com wrote:
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: 13 March 2014 13:24
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: dom requires PROP_loops
Probably RTL cfgcleaup needs the same treatment as GIMPLE cfgcleanup
then - allow removal if loop properties allows it.
In both cfgcleanup.c and tree-cfgcleanup.c I can see code that protects
loop latches, but I see no code that allows removal of latch if
property allows it.
From what you say I would expect this would already be implemented in
tree-cfgcleanup.c, however what actually happens is that since
current_loops is non-null (PROP_loops is not destroyed in tree
loopdone), tree-cfgcleanup call chain ends up calling
cleanup_tree_cfg_bb on the bb loop latch and tree_forwarder_block_p
returns false for bb because of the following code thereby not removing
the latch:
if (current_loops)
{
basic_block dest;
/* Protect loop latches, headers and preheaders. */
if (bb-loop_father-header == bb)
return false;
dest = EDGE_SUCC (bb, 0)-dest;
if (dest-loop_father-header == dest)
return false;
}
Why do we need to protect the latch?
You are looking at old sources.
That's correct. I was looking at 4.8. Let me take a look at what trunk is
doing... :)
Richard.
Paulo Matos
Richard.
RE: dom requires PROP_loops
-Original Message- From: Richard Biener [mailto:richard.guent...@gmail.com] Sent: 11 March 2014 10:52 To: Paulo Matos Cc: gcc@gcc.gnu.org Subject: Re: dom requires PROP_loops On Mon, Mar 10, 2014 at 12:57 PM, Paulo Matos pma...@broadcom.com wrote: Hello, In an attempt to test some optimization I destroyed the loop property in pass_tree_loop_done and reinstated it in pass_rtl_loop_init, however then I noticed that pass_dominator started generating wrong code. My guess is that we should mark pass_dominator with PROP_loops as a required property? Do you agree? No, PROP_loops is something artificial. Passes needing loops will compute them (call loop_optimizer_init). You probably did sth wrong with how you destroy PROP_loops. Haven't done anything out of the ordinary. I actually copied what other passes do: cfun-curr_properties = ~PROP_loops; before calling loop_optimizer_finalize. I find it strange that you actually need to do this since something like this should be done automatically if you mark the property as being destroyed. The background of my investigation in to this is that we don't like instructions in loop latches. This blocks generation of zero-overhead loops for us. PROP_loops is enabled from tree loopinit to rtl loop_done2 and with this property enabled cfg_cleanup doesn't remove empty latches allowing GCC to move instructions into the latch in the meantime. If I destroy this property (as above) in tree_ssa_loop_done and recreate it in rtl loop_init we have major performance boost because CFG cleanup removes empty loop latches but I found a case when jump threading generates wrong code in this case. Richard.
Re: dom requires PROP_loops
On Thu, Mar 13, 2014 at 12:20 PM, Paulo Matos pma...@broadcom.com wrote: -Original Message- From: Richard Biener [mailto:richard.guent...@gmail.com] Sent: 11 March 2014 10:52 To: Paulo Matos Cc: gcc@gcc.gnu.org Subject: Re: dom requires PROP_loops On Mon, Mar 10, 2014 at 12:57 PM, Paulo Matos pma...@broadcom.com wrote: Hello, In an attempt to test some optimization I destroyed the loop property in pass_tree_loop_done and reinstated it in pass_rtl_loop_init, however then I noticed that pass_dominator started generating wrong code. My guess is that we should mark pass_dominator with PROP_loops as a required property? Do you agree? No, PROP_loops is something artificial. Passes needing loops will compute them (call loop_optimizer_init). You probably did sth wrong with how you destroy PROP_loops. Haven't done anything out of the ordinary. I actually copied what other passes do: cfun-curr_properties = ~PROP_loops; before calling loop_optimizer_finalize. That should work. Eventually. I find it strange that you actually need to do this since something like this should be done automatically if you mark the property as being destroyed. It was never entirely clear how properties were designed and certainly they are not used consistently. For 4.10 PROP_loops will eventually just go away. The background of my investigation in to this is that we don't like instructions in loop latches. This blocks generation of zero-overhead loops for us. PROP_loops is enabled from tree loopinit to rtl loop_done2 and with this property enabled cfg_cleanup doesn't remove empty latches allowing GCC to move instructions into the latch in the meantime. Isn't that fixed on trunk now? (for gimple cfgcleanup at least?) If I destroy this property (as above) in tree_ssa_loop_done and recreate it in rtl loop_init we have major performance boost because CFG cleanup removes empty loop latches but I found a case when jump threading generates wrong code in this case. Well, you also lose all meta-data attached to loops. Also which jump-threading? RTL or GIMPLE? On GIMPLE loops are requested from both jump-threading passes, DOM and VRP. Richard. Richard.
Re: dom requires PROP_loops
On Thu, Mar 13, 2014 at 1:58 PM, Paulo Matos pma...@broadcom.com wrote: -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo Matos Sent: 13 March 2014 11:21 To: Richard Biener Cc: gcc@gcc.gnu.org Subject: RE: dom requires PROP_loops PROP_loops is enabled from tree loopinit to rtl loop_done2 and with this property enabled cfg_cleanup doesn't remove empty latches allowing GCC to move instructions into the latch in the meantime. Let me clarify this statement. With PROP_loops enabled, loop_optimizer_finalize doesn't free loops and current_loops is non-null. This has an array of consequences, one of them being that loop latches are not removed. So, which PROP_loops is the reason for the non-removal of empty loop latches, removal actually depends on the value of current_loops. Probably RTL cfgcleaup needs the same treatment as GIMPLE cfgcleanup then - allow removal if loop properties allows it. Richard. -- Paulo Matos
RE: dom requires PROP_loops
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: 13 March 2014 13:24
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: dom requires PROP_loops
Probably RTL cfgcleaup needs the same treatment as GIMPLE cfgcleanup
then - allow removal if loop properties allows it.
In both cfgcleanup.c and tree-cfgcleanup.c I can see code that protects loop
latches, but I see no code that allows removal of latch if property allows it.
From what you say I would expect this would already be implemented in
tree-cfgcleanup.c, however what actually happens is that since current_loops is
non-null (PROP_loops is not destroyed in tree loopdone), tree-cfgcleanup call
chain ends up calling cleanup_tree_cfg_bb on the bb loop latch and
tree_forwarder_block_p returns false for bb because of the following code
thereby not removing the latch:
if (current_loops)
{
basic_block dest;
/* Protect loop latches, headers and preheaders. */
if (bb-loop_father-header == bb)
return false;
dest = EDGE_SUCC (bb, 0)-dest;
if (dest-loop_father-header == dest)
return false;
}
Why do we need to protect the latch?
Paulo Matos
Richard.
RE: dom requires PROP_loops
On March 13, 2014 5:00:53 PM CET, Paulo Matos pma...@broadcom.com wrote:
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: 13 March 2014 13:24
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: dom requires PROP_loops
Probably RTL cfgcleaup needs the same treatment as GIMPLE cfgcleanup
then - allow removal if loop properties allows it.
In both cfgcleanup.c and tree-cfgcleanup.c I can see code that protects
loop latches, but I see no code that allows removal of latch if
property allows it.
From what you say I would expect this would already be implemented in
tree-cfgcleanup.c, however what actually happens is that since
current_loops is non-null (PROP_loops is not destroyed in tree
loopdone), tree-cfgcleanup call chain ends up calling
cleanup_tree_cfg_bb on the bb loop latch and tree_forwarder_block_p
returns false for bb because of the following code thereby not removing
the latch:
if (current_loops)
{
basic_block dest;
/* Protect loop latches, headers and preheaders. */
if (bb-loop_father-header == bb)
return false;
dest = EDGE_SUCC (bb, 0)-dest;
if (dest-loop_father-header == dest)
return false;
}
Why do we need to protect the latch?
You are looking at old sources.
Richard.
Paulo Matos
Richard.
Re: dom requires PROP_loops
On Mon, Mar 10, 2014 at 12:57 PM, Paulo Matos pma...@broadcom.com wrote: Hello, In an attempt to test some optimization I destroyed the loop property in pass_tree_loop_done and reinstated it in pass_rtl_loop_init, however then I noticed that pass_dominator started generating wrong code. My guess is that we should mark pass_dominator with PROP_loops as a required property? Do you agree? No, PROP_loops is something artificial. Passes needing loops will compute them (call loop_optimizer_init). You probably did sth wrong with how you destroy PROP_loops. Richard. Cheers, Paulo Matos
dom requires PROP_loops
Hello, In an attempt to test some optimization I destroyed the loop property in pass_tree_loop_done and reinstated it in pass_rtl_loop_init, however then I noticed that pass_dominator started generating wrong code. My guess is that we should mark pass_dominator with PROP_loops as a required property? Do you agree? Cheers, Paulo Matos
