Beyond Complex Register Management

[Mike Stump <mikestump at comcast dot net>]

On Aug 8, 2012, at 8:38 AM, DJ Delorie wrote:
> The RL78 devirtualization pass is *not* a reorg pass, it has to happen
> after reload but before debug info is set up.  The RL78 does not have
> a consistent register set or addressing scheme, GCC cannot practically
> support it.

Gosh, we got one of those two, though, I don't know how much worse your machine is than mine, in at all.  For example, $fp is in register N, where N is calculated differently for each function and isn't known until compute_frame_size time.  Which registers can be used isn't known until then either.  Also, different parts of the prologue use totally different numbering.  We handle this by having many different copies of all the registers, one copy for each possible category of use, and the once we get a feel for the landscape, we pin everything (that's a lie, we only pin some things) down, mark up which registers are going to be disappeared or put into service, essentially, for a given register, it can only ever be live in one category.  Some of the categories have variable mappings (computed mappings) to the actual register, it isn't the case that the first register of category Y, maps to the same register as the first register of category Z. We also have different mappings depending where in the instruction stream the instruction falls, just for fun.  Now, we do all this, with no reorg or devirtualization pass.  I'd like to think what you do would be a proper subset of what we do.

So, for example, we have one category for call clobbered registers, one for caller saved register, one for inbound argument register, one for outbound argument registers, gosh, so many, I can't recall all the others...  The only magic we do have, is an extra call to reinit_regs in gimple_expand_cfg right before the if () fixup_tail_calls() code, so that TARGET_CONDITIONAL_REGISTER_USAGE has a chance to fire at just the right time.  That firing pins some of the aspects of argument registers and some of the other registers.  The rest of the pinning down is done at compute_frame_size time.  So, there isn't just one pinning, but two.  We handle the second pinning by dynamic code in print_operand.  regno = func (regno, codegen_state); printf ("%s", reg_name[regno]);  The style allows for an arbitrarily computed register number, based upon anything one wants.  We merely happen to use the frame information, leaf information, where in the instruction stream we are and a few other bits.  Our usual func, is something like:

  switch CATEGORY (regno)
    case 1:
	regno = regno-CATEGORY_BASE[1] + actual_start_category[1];  break;
    case 2:
        regno = regno-category_base[2] + actual_start_category[2];  break;
   [ ... ]

where the various category_bases are the start of the given categories and the actual_start_categories are the place to actually put the category in the actual register file.

So, if you want to explore how to redo the port, or if it is even possible, just let me know...  I like puzzles, but only if they aren't trivial.  :-)  The line count to switch your port is roughly O(NC*(ARPC/4 + 20) + 80), I suspect; where NC are the number of classes, and ARPC is the average registers per class.

Now, all that said, the code is pretty basic and clean and we think interfaces well with the rest of the compiler.  We don't violate gcc notion of codegen (though, we might get the DBX_REGISTER_NUMBER slightly wrong in the first part of the prologue).  I think even that problem can be fixed, if we want.

As we move to C++, I'd love for port maintainers to be able to get together and hoist _up_ code from the port so other ports can use it and thus, have more sharing.  We make heavily stylized uses, which could be wrapped into a prettier api, given a reasonably powerful language.  C++ might be powerful enough.  I'd love to see someone improve the FIXED_REGISTERS, REGISTER_NAMES, REG_CLASS_CONTENTS, REGNO_REG_CLASS, REGNO_GLOBAL_BASE_REG_P, CLASS_MAX_NREGS experience, as the current api sucks; for example.  I dread the slightest change to any of my registers, as the change ripples throughout a ton of disparate places, and it is currently too easy to forget one of them.  Bonus points for cleaning up TARGET_SECONDARY_RELOAD at the same time as the above.  I find that api sucks in ways I can't begin to describe.