Re: PATCH: extra machine-dependent passes

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Fri, 15 Jun 2001 19:47:52 -0400
> From: DJ Delorie <dj@redhat.com>
> CC: gcc@gcc.gnu.org
> X-OriginalArrivalTime: 15 Jun 2001 23:47:56.0274 (UTC) FILETIME=[99D06D20:01C0F5F5]
> 
> 
> > This sounds like something that would be useful in other ports than
> > yours.  Just about every port has a registers like this for doing PIC,
> > and there are lots of ports with few registers available (for
> > instance, x86 has both properties).  Can you implement this is a
> > generic way?
> 
> If I did, it would be fairly invasive, as many ports have a return
> address register that would use this feature.

You mean, for __builtin_return_address?  Yes, it could be used for
that.  The initial implementation wouldn't have to change all the
ports right now, though.

>  If there were some way
> of saying gen_rtx_REG (SImode, pseudo_for_initial_hard_reg_contents
> (4)) that would be better, but the allocator would need to know about
> that I think.  Currently I'm tagging the moves I add with unspecs, and
> using the post-inline pass to locate them and stitch them all
> together.
>
> I'm also more of a back-end dude (as if it weren't obvious ;), so I'd
> need guidance to go fiddling with that part of the code.
> 
> > It sounds like this would be best done at about the time of
> > instantiate_virtual_regs; it's really just passing a hidden argument
> > to the function.
> 
> No, *that* part is easy, and is done in lots of places (like alpha's
> alpha_return_addr()).  The real problem is with inlined functions,
> where the `argument registers' are handled differently.

I think you want to allocate a fixed register for each incoming
pseudo-argument, in the range after FIRST_PSEUDO_REGISTER where
currently such things as virtual_stack_dynamic_rtx live.  That way
they are the same for an inlined procedure and the procedure it is
inlined into.  Then, in instantiate_virtual_registers or so,
replace this with a pseudo.

> > This sounds like a register allocation problem.  Why doesn't the
> > allocator put them in their preferred registers automatically?  Does
> > the new allocator also do this?
> 
> It usually does, but sometimes doesn't, and it would be nice if I
> could give it a preference.  Since the usage spans blocks, local alloc
> doesn't consider it, and regmove doesn't either because there aren't
> any useful constraints for that purpose.

It already has a way of determining preferences.  If the constraints
clearly indicate that this register is mostly used in some class, that
class should be recorded in hard_reg_preferences in the allocno
structure in global-alloc.

> The worst case I've seen is where it allocates a different call-saved
> hard reg for that pseudo, so you see code like:
> 
> 	save reg X to stack
> 	move reg Y to reg X
> 	...
> 	restore Y from X
> 	restore X from stack

We already have lots and lots of code in the compiler that tries to
either avoid generating code like this, or remove it afterwards.  We
really don't need to add more; instead, we need to find out why the
code we already have isn't working for this case.

-- 
- Geoffrey Keating <geoffk@geoffk.org>