[PATCH] RC->contains is a trap... (PR16106)

[Jakob Stoklund Olesen]

On Jun 12, 2013, at 11:58 AM, Eric Christopher <echristo at gmail.com> wrote:

> Hi Jakob and Lang,
> 
> RC->contains is a trap for the register allocator since it tests the
> presence of the register in the class, however, it ignores any
> additions or removals done by an AltOrder and so shouldn't be used in
> this situation. The greedy allocator uses AllocationOrder, but the
> fast allocator doesn't and just grabs the order specifically when it
> needs it.
> 
> I see a few possible ways here:
> 
> a) the patch I've got,
> b) modify contains,
> c) use AllocationOrder in the fast allocator,
> d) something else (fix the hint? something?)
> 
> At any rate contains should probably go away or something. It just
> seems like a trap. I haven't audited all uses of contains throughout
> the compiler, but this appears to be the only use in any of the
> allocators.
> 
> Thoughts?

OK, here we go:

I don’t really like to think about the allocation order as defining the set of registers that can be used legally. I see it more as a hint to the register allocator about the preferred registers. Removing a register from the allocation order is a very strong hint to avoid it, but it shouldn’t be illegal.

In most cases, registers that are not supported by a particular subtarget can simply be reserved, like we do for r8-r15 and xmm8-xmm15.

TableGen is actually using the defined register classes to synthesize more register classes so that you get a closed algebra under intersection and sub-register operations. The idea is to provide enough register classes that MachineRegisterInfo::recomputeRegClass() can compute an exact answer.

If the set of legal registers is changed by the allocation order, TableGen isn’t using the right sets for its computations.

This constraint isn’t really causing any problems that I am aware of, except for the x86 8-bit registers. Even there, the problems only arise because the 32 and 64-bit subtargets have completely different encoding constraints.

On x86-64, we avoid using the ‘H’ 8-bit registers since they cannot be encoded in an instruction with a REX prefix. We don’t reserve them, though, since they are still useful in some cases. They are only ever used with the *_NOREX pseudo-instructions.

I think the problem comes from using the GR8 register class directly. It has too many registers both for 32-bit and 64-bit mode. I wonder if it would help to define a GR8_L register class containing only the low 8-bit registers (no sub_8bit_hi regs), and then use that as the legal register class for i8 on x86-64.

/jakob