[PATCH] Add a pass for constructing gc.statepoint sequences w/explicit relocations
listmail at philipreames.com
Thu Jan 29 10:50:04 PST 2015
(I would really appreciate a LGTM so that we can iterate in tree.)
On 01/23/2015 05:36 PM, Philip Reames wrote:
> 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
>> - 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.
>> EMAIL PREFERENCES
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
More information about the llvm-commits