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

[Owen Anderson]

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.

--Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4260 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20080630/ef1fdd99/attachment.bin>