------- Comment #6 from rguenther at suse dot de  2007-11-22 09:35 -------
Subject: Re:  [4.3 Regression] SCCVN breaks
 gettext

On Thu, 22 Nov 2007, dberlin at dberlin dot org wrote:

> ------- Comment #4 from dberlin at gcc dot gnu dot org  2007-11-22 04:48 
> -------
> Subject: Re:  [4.3 Regression] SCCVN breaks gettext
> 
> The real problem seems to me, at least unless you guys haven't pasted
> that part of the trace, that nitems_19 isn't part of the SCC but
> should be.  By the time iteration of the SCC finishes, we should have
> discovered that nitems_19 does not have the value 0.

The SCC looks complete.  The IL before FRE is

<bb 2>:

<bb 3>:
  # nitems_21 = PHI <0(2), nitems_20(9)>

<bb 4>:
  # nitems_1 = PHI <nitems_21(3), nitems_1(4)>
  D.1574_5 = hash_find_entry (&list);
  if (D.1574_5 == 0)
    goto <bb 5>;
  else
    goto <bb 4>;

<bb 5>:
  list.0_6 = list;
  D.1576_7 = *list.0_6;
  len2_8 = (size_t) D.1576_7;
  new_max_9 = nitems_1 + len2_8;
  if (new_max_9 != len2_8)
    goto <bb 10>;
  else
    goto <bb 6>;
<bb 6>:
  dest_10 = foo (new_max_9);
  goto <bb 8>;

<bb 7>:
  destptr_15 = destptr_3 + 8;

<bb 8>:
  # destptr_3 = PHI <dest_10(6), destptr_15(7)>
  # len2_2 = PHI <len2_8(6), len2_14(7)>
  len2_14 = len2_2 + 0x0ffffffffffffffff;
  if (len2_2 != 0)
    goto <bb 7>;
  else
    goto <bb 9>;

<bb 9>:
  destptr.2_16 = (long int) destptr_3;
  dest.3_17 = (long int) dest_10;
  D.1581_18 = destptr.2_16 - dest.3_17;
  D.1582_19 = D.1581_18 /[ex] 8;
  nitems_20 = (size_t) D.1582_19;
  goto <bb 3>;

<bb 10>:
  return 0;

and the offending SCC contains:

SCC consists of: nitems_21 nitems_1 new_max_9 dest_10 destptr_3 
destptr.2_16 dest.3_17 D.1581_18 D.1582_19 nitems_20 destptr_15

where it goes wrong is in the 2nd iteration where it doesn't figure
that destptr_3 != dest_10.  Note that I also don't believe arbitrary
wrong information in the optimistic table can ever lead to always
correct information with a new table in just one iteration.  Because
in our case we set the value number of nitems_20 to zero (and thus
the VN of nitems_21), so even with the correct tables we start
(and thus never change) with nitems_21 == 0.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34176

Reply via email to