Re: PATCH: extra machine-dependent passes

[DJ Delorie <dj at redhat dot com>]

> 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.  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.

> 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.

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