On May 15, 2018 5:04:53 PM GMT+02:00, Jeff Law <l...@redhat.com> wrote: >On 05/15/2018 02:15 AM, Richard Biener wrote: >> On Mon, 14 May 2018, Kugan Vivekanandarajah wrote: >> >>> Hi, >>> >>> Attached patch handles PR63185 when we reach PHI with temp != NULLL. >>> We could see the PHI and if there isn't any uses for PHI that is >>> interesting, we could ignore that ? >>> >>> Bootstrapped and regression tested on x86_64-linux-gnu. >>> Is this OK? >> >> No, as Jeff said we can't do it this way. >> >> If we end up with multiple VDEFs in the walk of defvar immediate >> uses we know we are dealing with a CFG fork. We can't really >> ignore any of the paths but we have to >> >> a) find the merge point (and the associated VDEF) >> b) verify for each each chain of VDEFs with associated VUSEs >> up to that merge VDEF that we have no uses of the to classify >> store and collect (partial) kills >> c) intersect kill info and continue walking from the merge point >Which makes me come back to "why is this structured as a forward walk?"
Probably historic reasons. We _do_ have a backward walk DSE embedded inside DCE though but I had troubles making it as powerful as DSE. >DSE seems much more naturally structured as a walk of the >post-dominator >tree, walking instructions in reverse order. DSE performs analysis for each possibly dead store and walks those in postdom order. But as the analysis decides whether a candidate is dead it needs to find later stores that makes it so. Thus a forward walk. The canonical way would possibly to find earlier stores that a store makes dead which would structure this more like a dataflow problem. (but the kill sets will be expensive to manage I'd guess) >Cases like 63185 would naturally fall out of that structure as the >clobber at the end of the function post-dominates the memset and >there's >no intervening aliased loads. > >In fact, I thought that's how I initially structured DSE. I'm not >sure when/why it changed. IIRC it was improved, became too expensive and then ended up the current way. Richard. >Jeff
