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

Philip Reames listmail at philipreames.com
Thu Jan 29 10:50:04 PST 2015


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




More information about the llvm-commits mailing list