Re: PATCH: extra machine-dependent passes

[Daniel Berlin <dan at cgsoftware dot com>]

DJ Delorie <dj@redhat.com> writes:

>> 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 new allocator should handle this properly, try it.
It's pretty stable, i've been using it for well over a month in daily
bootstraps and whatnot, and only have found one instance where it
failed to find a coloring, due to a problem that's already known and
listed as somethign to solve at the top of the file.

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

-- 
"I invented the cordless extension cord.
"-Steven Wright