This is an archive of the discontinued LLVM Phabricator instance.

[RS4GC] Don't clone BDV if its inputs are not derived
Changes PlannedPublic

Authored by dmakogon on Apr 15 2022, 1:52 AM.

Details

Summary

This patch performs check if all the inputs of the BDV are base values themselves (i.e. not derived from some base)
If it's true for some BDV, we can avoid cloning it, because the clone would be identical to BDV (it may have different incoming values, because those may be cloned too).

Diff Detail

Event Timeline

dmakogon created this revision.Apr 15 2022, 1:52 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 15 2022, 1:52 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
dmakogon requested review of this revision.Apr 15 2022, 1:52 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 15 2022, 1:52 AM
mkazantsev added inline comments.Apr 18 2022, 12:57 AM
llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp
725

What worries me is that we never check the consistency of state of IsDerived and BaseValue. There should be some invariant like "if BaseValue is defined and not equal to OriginalValue then IsDerived should be true", or whatsoever. Do you want to add some sanity checks to make sure these states are not self-contradictory?

Ideally I'd completely give up a separate boolean flag for IsDerived and answer the method through other fields, but not sure if it's possible.

1055
  1. If I'm reading this code correctly, ToRemove should already be empty and you can assert that instead.
  2. I don't feel comfortable using the same ToRemove vector for 2 different unrelated activities. Limit scope or declare a new one?
1056

Would that work here?

remove_if(States, [](It) { return !It.second.isDerived() ;}

?

1089

Please name the boolean parameter /* IsDerived*/ true

I'm also looking into this. The idea is clear but I worry this adds a complexity with decoding the state.
I'm looking into the way to make it more straightforward. Probably it will require some re-factoring.

nikic resigned from this revision.Apr 19 2022, 12:51 AM
dmakogon planned changes to this revision.Apr 20 2022, 11:31 AM
dmakogon updated this revision to Diff 424425.Apr 22 2022, 3:35 AM

Added new enum values instead of the isDerived flag.

Please go through all comments in findBasePointer and verify that they are up to date with you changes...

llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp
749

This is redundant, just use in place.

766–776

Add a comment.

dmakogon updated this revision to Diff 425219.Apr 26 2022, 8:01 AM

Add more comments, update present ones.
Also there was a crash in lambda getBaseForInput. It relied on the old enum values. Fixed it.

dmakogon marked 5 inline comments as done.Apr 26 2022, 8:01 AM

You're extending the algorithm in two ways at once. First, you're tracking whether a value which has a single base is itself that base pointer. Second, you're tracking whether a meet of two values is definitely a base pointer.

I see why the former is needed for the later, but can you get any benefit from only the former? If you can, separating that into it's own patch with tests would help reduce complexity. I think at a minimum you can use the former on its on to strengthen some asserts.

Another way to handle it would be to separate the "IsKnownBase" bit out of the lattice enum states, and track it separately. If you do that, please rename the lattice elements to reflect that they're tracking the number of contributing bases (e.g. unknown, onebase, manybases). We have some precedent for that in the BaseDefiningValueResult structure, so that somewhat makes sense.

llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp
710

Naming wise, let me suggest "IsBase" and "HasSingleBase" for the states you're currently calling "Base", and "Derived".

Why?

  1. This avoids the state name reuse which a) forces compile errors, and b) makes any missed comments much less confusing.
  1. Derived seems to imply the pointer must be derived, when in practice, I believe you mean that it may be derived.
dmakogon updated this revision to Diff 425232.Apr 26 2022, 8:50 AM

Removed unnecessary comment in test case

dmakogon planned changes to this revision.Apr 27 2022, 3:03 AM