PR 30194: temporary workaround

[Diego Novillo <dnovillo at redhat dot com>]

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:

 <L1>:;
   # 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:

<L1>:;
   # 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.