[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