[PATCH] Add a pass for inserting safepoints into (nearly) arbitrary IR

Philip Reames listmail at philipreames.com
Thu Jan 29 10:49:31 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 03:01 PM, Philip Reames wrote:
>> Hi whitequark, sanjoy, atrick, ributzka,
>>
>> This pass is responsible for figuring out where to place call 
>> safepoints and safepoint polls.  It doesn't actually make the 
>> relocations explicit; that's the job of the RewriteStatepointsForGC 
>> pass (http://reviews.llvm.org/D6975).
>>
>> Points for review:
>> - I'd like to get this landed relatively quickly.  This code is 
>> actually changing a bit as we work through optimization issues. For 
>> example, the SplitBackedge option was just added yesterday.
>> - I welcome suggestions on how to get rid of the nasty embedded pass 
>> manager trick.  I think at this point that can be replaced with a 
>> more normal analysis dependency, but I don't believe having a loop 
>> analysis pass as a dependency for a Module pass works.
>> - Once landed, I plan on restructuring the statepoint rewrite to use 
>> the functions add to the IRBuilder a while back.  I would prefer to 
>> do this as a separate change against TOT.
>> - In our version of this pass, it also handles inserting 
>> deoptimization state for the inserted safepoints.  Since that code is 
>> not yet ready to be upstreamed, I ripped it out.  This may get added 
>> at a later point.
>> - In the current pass, the function "gc.safepoint_poll" is treated 
>> specially but is not an intrinsic.  I plan to make identifying the 
>> poll function a property of the GCStrategy at some point in the near 
>> future.
>> - It's not explicit in the code, but these two patches are 
>> introducing a new state for a statepoint which looks a lot like a 
>> patchpoint. There's no a transient form which doesn't yet have the 
>> relocations explicitly represented, but does prevent reordering of 
>> memory operations.  Once this is in, I need to update actually make 
>> this explicit by reserving the 'unused' argument of the statepoint as 
>> a flag, updating the docs, and making the code explicitly check for 
>> such a thing.  This wasn't really planned, but once I split the two 
>> passes - which was done for other reasons - the intermediate state 
>> fell out.  Just reminds us once again that we need to merge 
>> statepoints and patchpoints at some point in the not that distant 
>> future.
>>
>> Future directions planned:
>> - Identifying more cases where a backedge safepoint isn't required to 
>> ensure timely execution of a safepoint poll.
>> - Tweaking the insertion process to generate easier to optimize IR.  
>> (For example, investigating making SplitBackedge) the default.
>> - Adding opt-in flags for a GCStrategy to use this pass.  Once done, 
>> add this pass to the actual pass ordering.
>>
>> http://reviews.llvm.org/D6981
>>
>> Files:
>>    include/llvm/IR/BasicBlock.h
>>    include/llvm/InitializePasses.h
>>    include/llvm/Transforms/Scalar.h
>>    lib/IR/BasicBlock.cpp
>>    lib/Transforms/Scalar/CMakeLists.txt
>>    lib/Transforms/Scalar/PlaceSafepoints.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