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?" DSE seems much more naturally structured as a walk of the post-dominator tree, walking instructions in reverse order.
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. Jeff
