[LLVMdev] Pointer vs Integer classification (was Re: make DataLayout a mandatory part of Module)

[Philip Reames]

On 02/24/2014 12:45 AM, Andrew Trick wrote:
>
> On Feb 21, 2014, at 10:37 AM, Philip Reames <listmail at philipreames.com 
> <mailto:listmail at philipreames.com>> wrote:
>
>>
>> On 02/14/2014 05:55 PM, Philip Reames wrote:
>>> Splitting out a conversation which started in "make DataLayout a 
>>> mandatory part of Module" since the topic has decidedly changed.  
>>> This also relates to the email "RFC: GEP as canonical form for 
>>> pointer addressing" I just sent.
>>>
>>> On 02/10/2014 05:25 PM, Nick Lewycky wrote:
>>>> ...
>>>>
>>>> We're supposed to have the llvm.gcroots intrinsic for this purpose, 
>>>> but you note that it prevents gc roots from being in registers 
>>>> (they must be in memory somewhere, usually on the stack), and that 
>>>> fixing it is more work than is reasonable.
>>> This is slightly off, but probably close to what I actually said 
>>> even if not quite what I meant.  :)
>>>
>>> I'm going to skip this and respond with a fuller explanation 
>>> Monday.  I'd written an explanation once, realized it was wrong, and 
>>> decided I should probably revisit when fully awake.
>>>
>>> Fundamentally, I believe that gc.roots could be made to work, even 
>>> with decent (but not optimal) performance in the end.  We may even 
>>> contribute some patches towards fixing issues with the gc.root 
>>> mechanism just to make a fair comparison.  I just don't believe it's 
>>> the right approach or the best way to reach the end goal.
>> So, not quite on Monday, but I did get around to writing up an 
>> explanation of what's wrong with using gcroot.  It turned out to be 
>> much longer than I expected, so I turned it into a blog post:
>> http://www.philipreames.com/Blog/2014/02/21/why-not-use-gcroot/
>>
>> The very short version: gcroot loses roots (for any GC) due to bad 
>> interaction with the optimizer, and gcroot doesn't capture all copies 
>> of a pointer root which fundamentally breaks collectors which 
>> relocate roots.  The only way I know to make gcroot (in its current 
>> form) work reliably for all collectors is to insert safepoints very 
>> early, which has highly negative performance impacts.  There are some 
>> (potentially) cheaper but ugly hacks available if you don't need to 
>> relocate roots.
>>
>> There's also going to be a follow up post on implementation problems, 
>> but that's completely separate from the fundamental problems.
>
> Thanks for the writeup. FWIW my understanding of gcroot has always 
> been that the call to invoke GC is “extern” and not readonly, so we 
> can’t do store->load forwarding on the escaped pointer across it. I 
> have never used gcroot myself.
Andy, I'm not clear what you're trying to say here.  Could you 
rephrase?  In particular, what do you mean by "call to invoke GC"?

Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140224/d3201a70/attachment.html>