[PATCH] Add a pass for constructing gc.statepoint sequences w/explicit relocations

Philip Reames listmail at philipreames.com
Mon Feb 9 15:23:25 PST 2015


ping x3

Can I get a signoff from someone?  This will evolve in tree, but having 
this out for review is starting to get awkward in terms of patch 
management.

Philip

On 01/29/2015 10:50 AM, Philip Reames wrote:
> ping x2
>
> (I would really appreciate a LGTM so that we can iterate in tree.)
>
> On 01/23/2015 05:36 PM, Philip Reames wrote:
>> ping
>>
>> On 01/14/2015 12:45 PM, Philip Reames wrote:
>>> Hi whitequark, sanjoy, hfinkel, atrick, ributzka,
>>>
>>> This patch consists of a single pass whose only purpose is to visit 
>>> previous inserted gc.statepoints which do not have gc.relocates 
>>> inserted yet, and insert them.  This is the meat of what I've been 
>>> terming 'late safepoint placement'.  The last remaining major piece 
>>> is identifying where the safepoints (in the form of gc.statepoints) 
>>> should be placed.  That code will follow in a separate patch in the 
>>> next week or so.
>>>
>>> NOTE ON REVIEW: I would *strongly* prefer to work on this 
>>> incrementally in tree.  In review comments, please try to 
>>> distinguish between 'must fix before submission' and 'please address 
>>> within near term'.  In particular, there are a number of style 
>>> naming violations I'm aware of and will fix, but would prefer to do 
>>> so after submission.
>>>
>>> The pass has several main subproblems it needs to address:
>>> - First, it has identify any live pointers.  In the current code, 
>>> the use of address spaces to distinguish pointers to GC managed 
>>> objects is hard coded, but this will become parametrizable in the 
>>> near future.  The actual liveness analysis is trivial (simply 
>>> dominance).  A follow on change will implement a more precise analysis.
>>> - Second, it has to identify base pointers for each live pointer.  
>>> This is a fairly straight forward data flow algorithm.  The current 
>>> implementation of said algorithm is bit messy, but unless someone 
>>> *strongly* objects, I'd prefer to leave that is for the moment.  
>>> This code has been fairly well exercised out of tree and I'd really 
>>> like to not make any changes to it until a) we have better in tree 
>>> tests covering this area and b) I've had a chance to back merge this 
>>> into our private tree.
>>> - Third, the information in the previous steps is used to actually 
>>> introduce rewrites.  Rather than trying to do this by hand, we 
>>> simply re-purpose the algorithm behind Mem2Reg to do this for us.
>>>
>>> Other planned follow up changes includes:
>>> - The gc.statepoint insertion ('safepoint placement') pass mentioned 
>>> previously.
>>> - The liveness algorithm improvements mentioned previously.
>>> - A per statepoint flag to indicate whether a particular statepoint 
>>> has been rewritten or not.
>>> - A GCStrategy hook to early exit the pass for non-gc code. This is 
>>> required before adding the pass to the actual pass order.
>>>
>>> http://reviews.llvm.org/D6975
>>>
>>> Files:
>>>    include/llvm/InitializePasses.h
>>>    include/llvm/Transforms/Scalar.h
>>>    lib/Transforms/Scalar/CMakeLists.txt
>>>    lib/Transforms/Scalar/RewriteStatepointsForGC.cpp
>>>    lib/Transforms/Scalar/Scalar.cpp
>>>
>>> EMAIL PREFERENCES
>>>    http://reviews.llvm.org/settings/panel/emailpreferences/
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list