This is the mail archive of the gcc-patches@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: PATCH: extra machine-dependent passes


On Fri, Jun 15, 2001 at 05:08:30PM -0400, DJ Delorie wrote:
> 
> > I think you need to describe the issue to the folks on the gcc list
> > before they can properly evaluate this patch.
> 
> OK, here's the background: The port I'm working on has a few registers
> that are similar to the MIPS gp register, but because of a shortage of
> registers, they must be available for general use also.  So, I emit a
> move to a pseudo at the beginning of the function, much like the alpha
> saves it's return address register, to keep track of that value.
> 
> However, when a function is inlined, the integrator "stitches
> together" the registers used for argument passing, but *not* these
> other registers.  So, I need to step in at that point and "finish the
> job" by finding all those special inlined moves and replacing the src
> with the pseudo from the parent function.

I could imagine a more MI pass that takes a HARD_REG_SET, which has 1 bits for
the special registers, and a macro return a new register for the first usage of
the special register (other instances of the same register would then use this
value).

	#define INLINE_REPLACE_INIT(HARD_REG_SET) \
		mymachine_special_regs (HARD_REG_SET)

	#define INLINE_REPLACE_FUNC(NEW, OLD, INSN) \
		(NEW) =  mymachine_new_reg ((OLD), (INSN))

If both macros are defined, then after inlining, iterate over the rtl,
determine whether the special registers are used, and if so replace them.

> The pre-alloc hook is intended to, at some point, try to force a
> preference for these pseudos to simply remain in their hard regs,
> since the chip is designed to work best that way.  GCC does OK without
> it, but not as good as I'd like in some cases.

I probably don't have enough information about what you want to do.

> > We *really* want to avoid adding these kinds of hooks.  They're
> > notoriously bad from a maintenance standpoint.
> 
> I'm open to suggestions, but nothing else has worked yet.  There's a
> huge gap between rtl generation and machine dependent reorg where the
> backend has little control over what's happening, and most of the
> hooks only work with optimization, which isn't sufficient for this
> case.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482


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