[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