This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: alpha bootstrap failure wrt loop


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~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]