This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: alpha bootstrap failure wrt loop
- To: Joern Rennecke <amylaar at cygnus dot co dot uk>, wilson at cygnus dot com
- Subject: Re: alpha bootstrap failure wrt loop
- From: Richard Henderson <rth at cygnus dot com>
- Date: Mon, 1 Feb 1999 18:54:28 -0800
- Cc: egcs-bugs at cygnus dot com, egcs-patches at cygnus dot com
- References: <19990130145933.A10496@cygnus.com> <199902011959.TAA27708@phal.cygnus.co.uk>
On Mon, Feb 01, 1999 at 07:59:25PM +0000, Joern Rennecke wrote:
> Hmm, there's still something odd about this: Doesn't move_movables generate
> a completely new set of insns? These new insns should all have uids
> that are >= max_uid_for_loop, and thus it doesn't matter where they are
> placed for the validity of uid_luid.
Good point, but perhaps doesn't affect the wrong value put
in start_luid.
----
Take ~rth/recog.i, configure alphaev56-linux, compile -O2.
Examine validate_replace_rtx_1, loop 1204 to 1328.
Badness is
giv at 1226 derived from 1353 as (reg:DI 553)
Although that reg 553 thing is a lie, it's actually reg 596.
Not sure what's wrong with the debugging output.
So for some reason insn 1353 is considered to be before insn 1226.
Examining the data at the start of recombine_givs, I see
max_uid_for_loop = 1354
insn 1353, giv_number 0, start_luid 415
insn 1226, giv_number 4, start_luid 574
Perhaps max_uid_for_loop is too high (1353 is preceeded by 1341 which
has an luid of 593, and succeeded by 1357, which is out of bounds),
but I don't know why that would be. It is set in loop_optimize and
not changed again.
Or actually, can someone tell me where the + 1 in
max_uid_for_loop = get_max_uid () + 1;
comes from? It's from
Sun Apr 12 21:08:28 1998 Jim Wilson <wilson@cygnus.com>
* loop.c (loop_optimize): Reset max_uid_for_loop after
find_and_verify_loops call.
r~