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]

PR 30194: temporary workaround

gcc.dg/pr19633-1.c has started exposing random failures after the mem-ssa merge. We are making different partitioning decisions because the order of the symbols in the partitioned alias set changed. So, sometimes we get one SFT into a partition which just happens to cross a call-site, and if it's added to the partition, we miss the optimization that removes the call to link_error.

In the failing case, the SFT associated with b.s.w is added to MPT.69.
So that we end up with:

   # MPT.69_8 = VDEF <MPT.69_7(D)> { MPT.69 }
   b.s.w = 3;
   # VUSE <SFT.54_9(D), SFT.55_10(D), SFT.56_11(D)> { SFT.54 SFT.55 SFT.56 SFT.62 }
   # SFT.62_13 = VDEF <SFT.62_12(D)>
   # MPT.69_14 = VDEF <MPT.69_8> { SFT.62 MPT.69 }
   x = bar1 (*c_1, *c_1);
   # VUSE <MPT.69_14> { MPT.69 }
   D.1993_6 = b.s.w;

Notice that the read from b.s.w will read from the call-clobbered
partition MPT.69.  So, we never propagate the value '3' to the read
from b.s.w.

But if aliases are stored in different order in the alias set
(different DECL_UID assignment), we just happen not to choose this SFT
for partitioning, leaving the IL as:

   # SFT.61_8 = VDEF <SFT.61_7(D)> { SFT.61 }
   b.s.w = 3;
   # VUSE <SFT.58_9(D), SFT.59_10(D), SFT.60_11(D), SFT.61_8> { SFT.58 SFT.59 SFT.60 SFT.61 }
   # MPT.69_13 = VDEF <MPT.69_12(D)> { MPT.69 }
   x = bar1 (*c_1, *c_1);
   # VUSE <SFT.61_8> { SFT.61 }
   D.1990_6 = b.s.w;

I will workaround this by increasing partitioning thresholds on this
test, for now, but I will leave the PR assigned to me while I figure
out better static partitioning heuristics.

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