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 <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. 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.
Jeff
