[PATCH] Statepoint infrastructure for garbage collection

[Philip Reames]

On 11/05/2014 06:00 PM, Andrew Trick wrote:
>
>> On Nov 5, 2014, at 5:28 PM, Philip Reames <listmail at philipreames.com 
>> <mailto:listmail at philipreames.com>> wrote:
>>
>> ================
>> Comment at: include/llvm/CodeGen/MachineInstr.h:91
>> @@ -90,3 +90,3 @@
>>
>> -  uint8_t NumMemRefs;                   // Information on memory 
>> references.
>> +  uint16_t NumMemRefs;                  // Information on memory 
>> references.
>>   mmo_iterator MemRefs;
>> ----------------
>> ributzka wrote:
>>> Are you really hitting the limitations of uint8_t for mem 
>>> references? Changing this by one byte increases the overall size of 
>>> a MachineInstr from 64 bytes to 72 bytes (due to padding).
>> We were at one point.  I'm not sure we still are.  I'm fine removing 
>> this in the change which initially gets upstreamed and revisiting 
>> this separately.
>
> Good, thanks. A lot of careful engineering went into packing 
> MachineInstr into 64 bytes in order to squeeze compile time out of 
> backend passes. And we still get complaints that machine code is too 
> slow to generate. If we need more MemRefs, we’ll have to come up with 
> another way to get them.
I'm happy to separate this, but looking at the surrounding fields, it 
looks like there are a few bits to spare.  The CommentFlags and Flags 
enums only need a combined 4 bits.  They're currently consuming 16 
bits.  And that's without even playing any tricks with tagged pointers.  :)

Restructuring this would definitely be a different change set though.

We might even be able to squeeze another word out of the structure, but 
I don't know enough about which fields are hot to be sure.  :)
>
> -Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141105/3f56bed9/attachment.html>