https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124362

--- Comment #10 from Jeffrey A. Law <law at gcc dot gnu.org> ---
SO I've gone throught the relatively small number of changes in the DOM3 dump
and the transformations look OK to me. 

We're particularly concerned about these PHI nodes at the start of bb 138:

  # _2193 = PHI <_1142(137), _453(460)>
  # prec_2386 = PHI <prec_1401(137), prec_2580(460)>

If we look at bb 137:

  # prec_1401 = PHI <prec_438(136)>
  # cstore_1468 = PHI <cstore_1042(136)>
  # value_1472 = PHI <value_1050(136)>
  _1568 = _2733 == 69;
  _1143 = (int) _1568;
  _1142 = _1143 + prec_1401;
  digits_1141 = _dtoa_r (data_583(D), value_1472, 2, _1142, &expt, &dsgn,
&rve);
  if (_2733 != 71)
    goto <bb 451>; [0.00%]
  else
    goto <bb 138>; [100.00%]

WHen DOM traverses 137->138 it will record _2377 == 71.  That's been around
forever.  But now it goes back and determines that _1568 == 0 and 1143 == 0
too, which in turn means that _1142 == prec_1401.

In bb460 we have:

  _2272 = _2733 == 69;
  _535 = (int) _2272;
  _453 = _535 + prec_2580;

And on the path to get to bb460 we know that _2377 has the value 71 already as
well.   That means that _2272 and _535 is zero and _453 == prec_2580.

So with 453 == prec_2580 and _1142 == prec_1401 let's look again at those
initial PHI nodes:

  # _2193 = PHI <_1142(137), _453(460)>
  # prec_2386 = PHI <prec_1401(137), prec_2580(460)>

That means that _2193 == prec_2386.  That was the equivalence I was worried
about when I took a quick peek last week.

I've looked at all the differences in the DOM dumps and I'm not seeing anything
wrong.  It's certainly finding and exploiting some new equivalences as noted
above, but they all look correct to me.

After the next VRP pass we see a lot more differences in the gimple dumps, but
they're primarily SSA_NAME_VERSION changes.

I'll build a map and verify the .optimized dump in the off chance DOM3 polluted
the global range/value data.  It's not trivial, but I think the number of
changes are still small enough to verify by hand.

I am starting to wonder more and more if this is a backend/target issue of some
kind exposed by the DOM changes.  Especially given the failure mode isn't
consistent run to run.

Reply via email to