This is the mail archive of the
mailing list for the GCC project.
Re: egcs-19980803 (pre-1.1) solaris regressions
- To: "David S. Miller" <davem at dm dot cobaltmicro dot com>
- Subject: Re: egcs-19980803 (pre-1.1) solaris regressions
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Tue, 18 Aug 1998 11:03:38 -0600
- cc: ghazi at caip dot rutgers dot edu, egcs-bugs at cygnus dot com, rth at cygnus dot com, tm at netcom dot com
- Reply-To: law at cygnus dot com
In message <199808181650.JAA29001@dm.cobaltmicro.com>you write:
> Actually I think it is a combination of bugs, 2 I can see at the
> 1) As you mention reorg is broken. I walked through the example and
> it does not find the basic blocks correctly and does not scan
> the necessary instructions to find resource usages while scheduling
> a delay instrution. In this case, it does not set the ANNUL bit in
> the instruction because of lost information.
Yea. This is nightmare code to deal with too. The ability to clean
up this mess is one of the big wins if we recompute live/dead and
block start/end info after reload.
> 2) Secondarily, I found another peculiar property of PIC during reload
> on Sparc. When the reload insns are output, a reference to the
> PIC register (%l7) is created but I can't for the life of me figure
> out where the compiler accounts for this fact in the register
> tables in any way shape or form. What gives?
Hmm. Presumably the usage of the PIC register happens behind reload's
back. ie, the pic reg is not a spill register and it's not already
mentioned elsewhere in the function before reload?
In that case I think it is the backend's responsibility to note that
the PIC register is in-use.
Note that having the PIC register come live behind reload's back can
lead to some problems. We've run into this on the PA, m68k, x86 and ppc.
Hopefully your PIC register is fixed and not a pseudo? And hopefully,
you always allocate a stack slot for it when -fpic/-fPIC?