[PATCH] Statepoint infrastructure for garbage collection

[Andrew Trick]

> On Nov 5, 2014, at 6:15 PM, Philip Reames <listmail at philipreames.com> wrote:
> 
> 
> 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.  :)

Yeah, stealing bits is fine. That’s what I meant by “come up with another way [to get MemRefs]”.

> 
> Restructuring this would definitely be a different change set though.

Definitely. Thanks.

> 
> 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/b78fb5ec/attachment.html>