| Message ID | alpine.LSU.2.11.1406251602360.29270@zhemvz.fhfr.qr |
|---|---|
| State | New |
| Headers | show |
On 06/25/14 08:05, Richard Biener wrote: > > This removes restrictions in DOM cprop_operand that inhibit > some optimizations. The volatile pointer thing is really realy > old and no longer necessary while the loop-depth consideration > is only valid for loop-closed PHI nodes (but we're not in > loop-closed SSA in DOM) - the coalescing is handled in out-of-SSA > phase by inserting copies appropriately. > > Bootstrapped on x86_64-unknown-linux-gnu, ok? > > Thanks, > Richard. > > 2014-06-25 Richard Biener <rguenther@suse.de> > > PR tree-optimization/61607 > * tree-ssa-dom.c (cprop_operand): Remove restriction on > propagating volatile pointers and on loop depth. The first hunk is OK. I thought we had tests for the do not copy propagate out of a loop nest in the suite. Did you check that tests in BZ 19038 still generate good code after this change? If we still generate good code for those tests, then this hunk is fine too. Jeff
On Wed, 25 Jun 2014, Jeff Law wrote: > On 06/25/14 08:05, Richard Biener wrote: > > > > This removes restrictions in DOM cprop_operand that inhibit > > some optimizations. The volatile pointer thing is really realy > > old and no longer necessary while the loop-depth consideration > > is only valid for loop-closed PHI nodes (but we're not in > > loop-closed SSA in DOM) - the coalescing is handled in out-of-SSA > > phase by inserting copies appropriately. > > > > Bootstrapped on x86_64-unknown-linux-gnu, ok? > > > > Thanks, > > Richard. > > > > 2014-06-25 Richard Biener <rguenther@suse.de> > > > > PR tree-optimization/61607 > > * tree-ssa-dom.c (cprop_operand): Remove restriction on > > propagating volatile pointers and on loop depth. > The first hunk is OK. > > I thought we had tests for the do not copy propagate out of a loop nest in the > suite. Did you check that tests in BZ 19038 still generate good code after > this change? If we still generate good code for those tests, then this hunk > is fine too. I have applied the first hunk and will investigate further. Testing didn't show any issue and I know how to retain the check but not cause the missed optimization shown in PR61607. Richard.
Index: gcc/tree-ssa-dom.c =================================================================== --- gcc/tree-ssa-dom.c (revision 211969) +++ gcc/tree-ssa-dom.c (working copy) @@ -2247,22 +2247,6 @@ cprop_operand (gimple stmt, use_operand_ if (!may_propagate_copy (op, val)) return; - /* Do not propagate addresses that point to volatiles into memory - stmts without volatile operands. */ - if (POINTER_TYPE_P (TREE_TYPE (val)) - && TYPE_VOLATILE (TREE_TYPE (TREE_TYPE (val))) - && gimple_has_mem_ops (stmt) - && !gimple_has_volatile_ops (stmt)) - return; - - /* Do not propagate copies if the propagated value is at a deeper loop - depth than the propagatee. Otherwise, this may move loop variant - variables outside of their loops and prevent coalescing - opportunities. If the value was loop invariant, it will be hoisted - by LICM and exposed for copy propagation. */ - if (loop_depth_of_name (val) > loop_depth_of_name (op)) - return; - /* Do not propagate copies into simple IV increment statements. See PR23821 for how this can disturb IV analysis. */ if (TREE_CODE (val) != INTEGER_CST