[LLVMdev] Register class proliferation

Jakob Stoklund Olesen stoklund at 2pi.dk
Tue Jun 21 08:51:37 PDT 2011


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?

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.

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.

/jakob





More information about the llvm-dev mailing list