[SVE] PR91532

[Richard Biener]

On Sun, 29 Sep 2019, Jeff Law wrote:

> On 9/26/19 12:44 AM, Richard Biener wrote:
> > On Wed, 25 Sep 2019, Prathamesh Kulkarni wrote:
> > 
> >> On Fri, 20 Sep 2019 at 15:20, Jeff Law <law@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.
> We've speculated for a while that some of these dominator walking
> optimizers could be extended to handle cases where the caller specifies
> what blocks are "of interest".  Bin was pretty far down this path for
> DOM which is probably the most complex.  Maybe that could be resurrected
> in the context of DSE.

Note that DSE is way easier than DOM, it's use of a dominator walk
is probably entirely historical given the fact that we only need to
walk the factored virtual SSA chain.  So a (SESE) region is
represented by two virtual SSA names (and for a loop in the ifcvt
context by its virtual PHI in the loop header).

The issue with if-conversion and dominators is that if-conversion
does analysis + transform loop-by-loop which means we at least
wreck the fast dominator access by doing CFG transforms between
analyzing separate loops in a function.  The pass is in need of
factoring to do analysis of all loops upfront and only then
transform.  The cleanup phase would then be after re-computing
dominators.

Richard.