[SVE] PR91532

[Jeff Law]

On 9/30/19 12:49 AM, Richard Biener wrote:
> 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.
If we're looking at something that is local to a block, then,
conceptually we'd just process the one interesting block.  In theory the
wrecked fast dominator access wouldn't matter.

What's more important in my mind is the state of the SSA graph.

Jeff