On 05/13/2018 09:37 PM, 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?
>
> Thanks,
> Kugan
>
>
> gcc/ChangeLog:
>
> 2018-05-14 Kugan Vivekanandarajah <kug...@linaro.org>
>
> * tree-ssa-dse.c (phi_dosent_define_nor_use_p): New.
> (dse_classify_store): Use phi_dosent_define_nor_use_p.
>
> gcc/testsuite/ChangeLog:
>
> 2018-05-14 Kugan Vivekanandarajah <kug...@linaro.org>
>
> * gcc.dg/tree-ssa/ssa-dse-33.c: New test.
>
So in this case the PHI post-dominates the store.
;; basic block 2, loop depth 0
;; pred: ENTRY
# .MEM_3 = VDEF <.MEM_2(D)>
p_4 = malloc (1024);
# .MEM_5 = VDEF <.MEM_3>
memset (p_4, 8, 1024);
if (n_6(D) != 0)
goto <bb 3>; [INV]
else
goto <bb 4>; [INV]
;; succ: 3
;; 4
;; basic block 3, loop depth 0
;; pred: 2
# .MEM_7 = VDEF <.MEM_5>
g ();
;; succ: 4
;; basic block 4, loop depth 0
;; pred: 2
;; 3
# .MEM_1 = PHI <.MEM_5(2), .MEM_7(3)>
# VUSE <.MEM_1>
return;
;; succ: EXIT
}
So the overall processing in this case is something like this:
We call into dse_classify_store for the memset. The first immediate use
is the call to g(), which does not do an aliased read. So we set TEMP
to g() and continue processing immediate uses.
We then process the PHI as an immediate use. We fail to walk through
the PHI because we've already walked through the call to g() (as
indicated by g() being stored in TEMP).
I think we can get the effect we want by realizing that the PHI is a
sink for the statement in TEMP. That in turn allows the existing
mechanisms to walk through the PHI to work. We would have to somehow
verify that we hadn't cleared anything in LIVE_BYTES though.
Jeff
