This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [SVE] PR91532

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]