[LLVMdev] Register class proliferation
Jakob Stoklund Olesen
stoklund at 2pi.dk
Tue Jun 21 10:20:42 PDT 2011
On Jun 21, 2011, at 9:23 AM, Jim Grosbach wrote:
>
> 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.
I can't think of any super-linear algorithms remaining except for getCommonSubClass() which could easily be fixed. I've never seen it show up on a Shark trace, though.
If we give each register class a bit vector of sub-classes, the currently linear isSubClass() / isSuperClass() would become constant time, and getCommonSubClass() could be made linear with CountTrailingZeros(A and B).
Yes, those bit vectors would require N^2 space, but the constant factor is 1 bit, so I don't care. I am not adding that many register classes.
/jakob
More information about the llvm-dev
mailing list