This is an archive of the discontinued LLVM Phabricator instance.

Add a pass for constructing gc.statepoint sequences w/explicit relocations
AbandonedPublic

Authored by reames on Jan 14 2015, 12:44 PM.

Details

Summary

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.

Diff Detail

Event Timeline

reames updated this revision to Diff 18176.Jan 14 2015, 12:44 PM
reames retitled this revision from to Add a pass for constructing gc.statepoint sequences w/explicit relocations.
reames updated this object.
reames edited the test plan for this revision. (Show Details)
reames added a subscriber: Unknown Object (MLST).
sanjoy edited edge metadata.Jan 14 2015, 2:10 PM

Overall, the main issues are obvious stylistic issues. Specifically:

  • using LLVM-specific data structures, like DenseSet and DenseMap instead of the std:: counterparts.
  • using LLVM variable and function naming conventions.
  • using C++ style comments

I have some small nits inline representative of the three points above.

My two cents is that you should get some of the low-hanging fruit in terms of the above three aspects before checking in, and then fix the rest incrementally once the pass is in tree.

lib/Transforms/Scalar/RewriteStatepointsForGC.cpp
13

An example here will make what this pass does clearer.

60

I this this should be removed before checking in.

90

C++ style comments please.

105

The field names of this struct don't follow the usual CamelCaseStartingWithUpperCase llvm style.

107

DenseSet?

110

DenseMap? Also applies to other fields in this struct.

161

LLVM style says bool Bad.

169

C++ style comments please.

214

If we pass in DT we can potentially get a stronger assertion.

262

I think this can be

if (a->hasName() || b->hasName())
  return a->getName() < b->getName();
return a < b;
392

This needs to be documented.

454

I don't think this is Java specific -- the language should be changed to reflect that.

499

I'd be more comfortable if this function explicitly returned a sum type or something like that.

512

Use llvm_unreachable. Also, can we do errs() << "unknown type: " << *I << "\n"?

681

C++ style comments please.

ping x2

(I would really appreciate a LGTM so that we can iterate in tree.)

reames added a comment.Feb 9 2015, 3:23 PM

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

atrick edited edge metadata.Feb 9 2015, 11:24 PM

I agree with Sanjoy's comments. I'm not sure why you're opposed to cleaning up the code before submitting it for review:

  • using LLVM's ADT containers
  • following LLVM naming conventions (violated in a few places).
  • following LLVM comment style!

Is it becase you want more feedback on the algorithm itself first?

You say you plan "The liveness algorithm improvements mentioned previously." Do you just mean the improvements listed above in the commit message?

There isn't really any liveness analysis here at all. The LiveVariables approach is pretty good for SSA liveness, so you could just steal it. From your comments I gather your saving that as a follow up improvement.

If you fix the obvious style issues, I don't really object to this being in trunk. We've already established that the pass will be on trunk (but not in the standard pipeline).

Once in trunk, if you want more feedback on certain aspects of the pass, whether design or implementation, you'll just have to be clear on what kind of review you want.

lib/Transforms/Scalar/RewriteStatepointsForGC.cpp
163

This "bad" variable name is mysterious. In this scope, it doesn't seem "bad".

I submitted a slightly cleaned up version of this in 229945. I included most of the easy to fix and merge changes mentioned by Sanjoy. I plan on leaving this review open until all the style comments have been addressed. Once I've completed everything I already know of, I'll upload a revised diff for a more typical review cycle.

Is there anything more to be done here?

sanjoy resigned from this revision.Jun 9 2015, 1:39 PM
sanjoy removed a reviewer: sanjoy.

I don't think there is anything more to be done here. Resigning so that it does not show up in my review queue.

reames abandoned this revision.Jun 10 2015, 4:00 PM

Long since submitted.