This is the mail archive of the
mailing list for the GCC project.
Re: egcs-19980803 (pre-1.1) solaris regressions
- To: law at cygnus dot com
- Subject: Re: egcs-19980803 (pre-1.1) solaris regressions
- From: "David S. Miller" <davem at dm dot cobaltmicro dot com>
- Date: Tue, 18 Aug 1998 10:44:26 -0700
- CC: ghazi at caip dot rutgers dot edu, egcs-bugs at cygnus dot com, rth at cygnus dot com, tm at netcom dot com
- References: <firstname.lastname@example.org>
Date: Tue, 18 Aug 1998 11:03:38 -0600
From: Jeffrey A Law <email@example.com>
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.
Indeed, and I still want to implement pre-delay slots for sake of
Sparc FPU branches as well...
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?
It gets used behind reloads back, and it is acquired for register
allocation as well. It is fine to use it normally before register
allocation, but if reload_in_progress we should note what we are
In that case I think it is the backend's responsibility to note that
the PIC register is in-use.
So I should update basic_block_live_at_start, or other things as well?
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.
Do other ports handle this by updating the alloc/reload tables? I
should go check what other people do wrt. this. I don't want to mark
it as not allocatable at all. (a quick check shows that ix86 marks it
as fixed, aieee thats nuts!)
Hopefully your PIC register is fixed and not a pseudo? And hopefully,
you always allocate a stack slot for it when -fpic/-fPIC?
It is fixed (but rth and I want to change this so functions which use
PIC can still be made leaf functions). I need to go over how we do
all of this on Sparc, LEGITIMATE_PIC_OPERAND_P seems suspicious at the
moment and actually could be the true root of the problem I am seeing
An emacs abbrev-mode fart? :-)
David S. Miller