[llvm-commits] [llvm] r52945 - in /llvm/trunk: include/llvm/Target/TargetRegisterInfo.h lib/Target/TargetRegisterInfo.cpp utils/TableGen/RegisterInfoEmitter.cpp

[Chris Lattner]

On Jun 30, 2008, at 9:02 PM, Owen Anderson wrote:

>
> On Jun 30, 2008, at 6:06 PM, Chris Lattner wrote:
>>> =
>>> =
>>> ====================================================================
>>> --- llvm/trunk/utils/TableGen/RegisterInfoEmitter.cpp (original)
>>> +++ llvm/trunk/utils/TableGen/RegisterInfoEmitter.cpp Mon Jun 30
>>> 19:18:52 2008
>>> @@ -462,6 +462,70 @@
>>>                    RegisterAliases);
>>>   }
>>> }
>>> +
>>> +  // Print the SubregHashTable, a simple quadratically probed
>>> +  // hash table for determining if a register is a subregister
>>> +  // of another register.
>>> +  unsigned SubregHashTableSize = NextPowerOf2(2 * Regs.size());
>>> +  unsigned* SubregHashTable =
>>> +                  (unsigned*)malloc(2 * SubregHashTableSize *
>>> sizeof(unsigned));
>>
>> Please use new[]/delete[] instead of malloc/free.  Does this really
>> guarantee that the hash table is sparse enough?  If I had 31
>> registers, would this make a table of size 32?  For a probed hash
>> table like this, you want at least 30-40% sparsity.
>>
>
> The number of entries in the hash table is equal to the number of  
> subregister relationship.  In theory this could be as big as n^2/2,  
> but it won't ever be in practice.  As for your example. you forgot  
> the doubling.  So for 31 registers, there would be 64 slots, which  
> seems reasonable in practice.  Remember that the number of registers  
> includes condition codes, vector registers, etc.

I thought the doubling was due to each entry taking two slots?

In any case, this seems like an even worse approximation for the hash  
table size.  What do you think of nextpow2(nsubregs*1.3)?

Using # subreg relationships as the base is important.  Targets like  
ia64 have no subregs but a huge number of regs, so the table should be  
small for it (1 pair of entries!)

-Chris