Re: Infinite loop in init_alias_analysis

[Jeffrey A Law <law at cygnus dot com>]

  In message <199711042032.VAA16414@Rivendell.MiddleEarth.net>you write:
  > I'll try :-)
Thanks.

  > We seem to agree on the state of things after the first iteration
  > through the loop;
Yup.  Having HJ's alpha failure to look at was a big help too.  This
is a case where an RTL dump from the pass before the alias code hung
would have been quite useful since I can't just build your target
and look at it under the debugger :-)


  > we have:
  >   reg_base_value[1]  == (reg/v:HI 24)
  >   ...
  >   reg_base_value[24] == (address (reg:HI 1 %r3))
  > which were copied from new_reg_base_value.
Right.  Just to be sure.  I assume you've got something like this
in your RTL dump:

(set (reg 24) (reg 1)
NOTE_INSN_FUNCTION_BEGIN
...
(set (reg 1) (reg 24))
...


HJ's alpha example is actually one copy deeper, but the same
basic problem:

(set (reg 68) (reg 16))
NOTE_INSN_FUNCTION_BEGIN
...
(set (reg 69) (reg 68))
...
(set (reg 16) (reg 69))

After the first iteration we have:

reg_base_value[16] = (reg 69)
               68  = (address (reg 16))
               69  = (reg 68)

Which sets up up for the same kind of loop that I think you're
running into (the three values just keep rotating around in the
values arrays).

For some reason I didn't run into this on the PA, or sparc when
I bootstrapped them, though I don't know why since it seems like
it's a pretty generic problem.  The x86 didn't exhibit this failure
because it doesn't pass args in registers.

  > Now we start a new iteration.  find_base_value is called (line 269 of alias.c) 
  > with (reg:HI 1 %r3) and, since reg_base_value[1]  contains (reg/v:HI 24), returns 
  > (reg/v:HI 24).
Right.  I think my confusion was your register number/names didn't
mentally make sense to me -- (reg:HI 1 %r3) (register #1, name %r3),
I kept thinking that should refer to reg_base_value[3].

I see it now :-)

  > Not allowing to return reg_base_value when it is the same as the
  > argument of find_base_value...
Now that I've had a chance to look at the code, I suspect either
your solution or mine will work.  Mine converges quicker, but I'm
somewhat leery that for some weird example the quicker convergence
might be to the wrong state :(

  > I hope I was more clear this time.
Yup.  I'm going to add a comment or two and use your solution.

jeff