On Thu, 3 Oct 2019, Prathamesh Kulkarni wrote:
> On Wed, 2 Oct 2019 at 12:28, Richard Biener <rguent...@suse.de> wrote:
> >
> > On Wed, 2 Oct 2019, Prathamesh Kulkarni wrote:
> >
> > > On Wed, 2 Oct 2019 at 01:08, Jeff Law <l...@redhat.com> wrote:
> > > >
> > > > On 10/1/19 12:40 AM, Richard Biener wrote:
> > > > > On Mon, 30 Sep 2019, Prathamesh Kulkarni wrote:
> > > > >
> > > > >> On Wed, 25 Sep 2019 at 23:44, Richard Biener <rguent...@suse.de>
> > > > >> wrote:
> > > > >>>
> > > > >>> On Wed, 25 Sep 2019, Prathamesh Kulkarni wrote:
> > > > >>>
> > > > >>>> On Fri, 20 Sep 2019 at 15:20, Jeff Law <l...@redhat.com> wrote:
> > > > >>>>>
> > > > >>>>> On 9/19/19 10:19 AM, Prathamesh Kulkarni wrote:
> > > > >>>>>> Hi,
> > > > >>>>>> For PR91532, the dead store is trivially deleted if we place dse
> > > > >>>>>> pass
> > > > >>>>>> between ifcvt and vect. Would it be OK to add another instance
> > > > >>>>>> of dse there ?
> > > > >>>>>> Or should we add an ad-hoc "basic-block dse" sub-pass to ifcvt
> > > > >>>>>> that
> > > > >>>>>> will clean up the dead store ?
> > > > >>>>> I'd hesitate to add another DSE pass. If there's one nearby
> > > > >>>>> could we
> > > > >>>>> move the existing pass?
> > > > >>>> Well I think the nearest one is just after pass_warn_restrict. Not
> > > > >>>> sure if it's a good
> > > > >>>> idea to move it up from there ?
> > > > >>>
> > > > >>> You'll need it inbetween ifcvt and vect so it would be disabled
> > > > >>> w/o vectorization, so no, that doesn't work.
> > > > >>>
> > > > >>> ifcvt already invokes SEME region value-numbering so if we had
> > > > >>> MESE region DSE it could use that. Not sure if you feel like
> > > > >>> refactoring DSE to work on regions - it currently uses a DOM
> > > > >>> walk which isn't suited for that.
> > > > >>>
> > > > >>> if-conversion has a little "local" dead predicate compute removal
> > > > >>> thingy (not that I like that), eventually it can be enhanced to
> > > > >>> do the DSE you want? Eventually it should be moved after the local
> > > > >>> CSE invocation though.
> > > > >> Hi,
> > > > >> Thanks for the suggestions.
> > > > >> For now, would it be OK to do "dse" on loop header in
> > > > >> tree_if_conversion, as in the attached patch ?
> > > > >> The patch does local dse in a new function ifcvt_local_dse instead of
> > > > >> ifcvt_local_dce, because it needed to be done after RPO VN which
> > > > >> eliminates:
> > > > >> Removing dead stmt _ifc__62 = *_55;
> > > > >> and makes the following store dead:
> > > > >> *_55 = _ifc__61;
> > > > >
> > > > > I suggested trying to move ifcvt_local_dce after RPO VN, you could
> > > > > try that as independent patch (pre-approved).
> > > > >
> > > > > I don't mind the extra walk though.
> > > > >
> > > > > What I see as possible issue is that dse_classify_store walks virtual
> > > > > uses and I'm not sure if the loop exit is a natural boundary for
> > > > > such walk (eventually the loop header virtual PHI is reached but
> > > > > there may also be a loop-closed PHI for the virtual operand,
> > > > > but not necessarily). So the question is whether to add a
> > > > > "stop at" argument to dse_classify_store specifying the virtual
> > > > > use the walk should stop at?
> > > > I think we want to stop at the block boundary -- aren't the cases we
> > > > care about here local to a block?
> > > This version restricts walking in dse_classify_store to basic-block if
> > > bb_only is true,
> > > and removes dead stores in ifcvt_local_dce instead of separate walk.
> > > Does it look OK ?
> >
> > As relied to Jeff please make it trivially work for SESE region walks
> > by specifying the exit virtual operand to stop on.
> Thanks for the suggestions, does the attached patch look OK ?
> Um, sorry, I don't really understand why we need to specify virtual
> phi arg from back edge to stop the walk.
> Would it achieve the same effect if we pass index of loop->latch to
> stop the walk ?
Since DSE walks the virtual def->use chain it makes sense to stop
it at a specific virtual definition. Note
@@ -706,7 +699,9 @@ dse_classify_store (ao_ref *ref, gimple *stmt,
FOR_EACH_IMM_USE_STMT (use_stmt, ui, defvar)
{
/* Limit stmt walking. */
- if (++cnt > PARAM_VALUE (PARAM_DSE_MAX_ALIAS_QUERIES_PER_STORE))
+ if (++cnt > PARAM_VALUE (PARAM_DSE_MAX_ALIAS_QUERIES_PER_STORE)
+ || (stop_at_vuse
+ && gimple_vuse (use_stmt) == stop_at_vuse))
{
can be done above this loop:
diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
index ba67884a825..bc95c21e52c 100644
--- a/gcc/tree-ssa-dse.c
+++ b/gcc/tree-ssa-dse.c
@@ -701,6 +701,9 @@ dse_classify_store (ao_ref *ref, gimple *stmt,
}
else
defvar = gimple_vdef (temp);
+ /* If we are instructed to stop walking at region boundary, do so.
*/
+ if (defvar == stop_at_vuse)
+ return DSE_STORE_LIVE;
auto_vec<gimple *, 10> defs;
gimple *phi_def = NULL;
FOR_EACH_IMM_USE_STMT (use_stmt, ui, defvar)
The way you find the virtual PHI is also too complicated. I'd do
@@ -2873,7 +2873,7 @@ ifcvt_split_critical_edges (class loop *loop, bool
aggressive_if_conv)
loop vectorization. */
static void
-ifcvt_local_dce (basic_block bb)
+ifcvt_local_dce (class loop *loop)
{
gimple *stmt;
gimple *stmt1;
@@ -2890,6 +2890,10 @@ ifcvt_local_dce (basic_block bb)
replace_uses_by (name_pair->first, name_pair->second);
redundant_ssa_names.release ();
+ /* The loop has a single BB only. */
+ basic_block bb = loop->header;
+ tree latch_vdef = NULL_TREE;
+
worklist.create (64);
/* Consider all phi as live statements. */
for (gsi = gsi_start_phis (bb); !gsi_end_p (gsi); gsi_next (&gsi))
@@ -2897,6 +2901,8 @@ ifcvt_local_dce (basic_block bb)
phi = gsi_stmt (gsi);
gimple_set_plf (phi, GF_PLF_2, true);
worklist.safe_push (phi);
+ if (virtual_operand_p (gimple_phi_result (phi)))
+ latch_vdef = PHI_ARG_DEF_FROM_EDGE (phi, loop_latch_edge (loop));
}
/* Consider load/store statements, CALL and COND as live. */
for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
> Thanks,
> Prathamesh
> >
> > Richard.
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 247165 (AG München)
