[LLVMdev] Register class proliferation

[Jim Grosbach]

On Jun 21, 2011, at 8:51 AM, Jakob Stoklund Olesen wrote:

> In the past, I've seen some pushback on the list against adding more register classes. You can see it in the code as well, TargetLowering::getRegClassForInlineAsmConstraint() returns a vector of registers instead of a real register class.
> 
> What is the reason we don't like adding register classes? Is it still a valid reason?
> 

As I recall, it's a performance issue, as some of the algorithms involved were non-linear and expensive. I think you've refactored most of that away by now, though.

> The new register allocators, fast and greedy, don't care at all. Their performance is independent of the number of register classes. Linear scan is running some kind of union find on the register classes, but should be fine otherwise.
> 
> I noticed that TableGen's asm matcher generator does stuff with register classes. It is possible it should be fixed so it only looks at register classes that are explicitly mentioned by instructions.

Having the other classes show up there shouldn't interfere with what's going on (InstAlias printing mechanism uses them). It might make for prettier output if we limit it to explicit user classes, but I don't expect it'll be strictly necessary.

> 
> I want register classes to be cheap, and I want TableGen to generate some of them automatically. The register allocators use them as constraints, and the coalescer wants to combine constraints. That is not always possible today because the register class representing the desired constraint is missing. If TableGen could fill in the gaps, we would get better coalescing.

This makes a lot of sense.

-Jim