This is an archive of the discontinued LLVM Phabricator instance.

[RewriteStatepointsForGC] Reduce the number of new instructions for base pointers
ClosedPublic

Authored by reames on Aug 12 2015, 5:45 PM.

Details

Summary

When computing base pointers, we introduce new instructions to propagate the base of existing instructions which might not be bases. However, the algorithm doesn't make any effort to recognize when the new instruction to be inserted is the same as an existing one already in the IR. Since this is happening immediately before rewriting, we don't really have a chance to fix it after the pass runs without teaching loop passes about statepoints.

I'm really not thrilled with this patch. I've rewritten it 4 different ways now, but this is the best I've come up with. The case where the new instruction is just the original base defining value could be merged into the existing algorithm with some complexity. The problem is that we might have something like an extractelement from a phi of two vectors. It may be trivially obvious that the base of the 0th element is an existing instruction, but I can't see how to make the algorithm itself figure that out. Thus, I resort to the call to SimplifyInstruction instead.

Note that we can only adjust the instructions we've inserted ourselves. The live sets are still being tracked in side structures at this point in the code. We can't easily muck with instructions which might be in them. Long term, I'm really thinking we need to materialize the live pointer sets explicitly in the IR somehow rather than using side structures to track them.

Diff Detail

Event Timeline

reames updated this revision to Diff 32014.Aug 12 2015, 5:45 PM
reames retitled this revision from to [RewriteStatepointsForGC] Reduce the number of new instructions for base pointers.
reames updated this object.
reames added reviewers: sanjoy, chenli, igor-laevsky.
reames added a subscriber: llvm-commits.
sanjoy edited edge metadata.Aug 14 2015, 4:40 PM

I don't see any particular problem with the code, but I have a few questions (inline) to ensure that I've understood the code correctly.

lib/Transforms/Scalar/RewriteStatepointsForGC.cpp
1018

There are some whitespace issues here -- do you mind running this patch through clang-format before checkin?

1020

Should be Item.

1032

Can't this set be populated as we create the instructions above?

1048

Can PushNewUsers(BaseI) be hoisted out of this if block with a if (Visited.insert(BaseI).second) check? Or does this need to remain conditional for correctness?

1055

I'd hoist this bit outside the loop.

1057

Will re-pushing V onto Worklist help? I'm thinking of cases where SimplifyInstruction(BaseI)->isIdenticalTo(BdvI).

Anything I didn't explicitly comment on, I accept and will address in a revised patch once the comments are settled.

lib/Transforms/Scalar/RewriteStatepointsForGC.cpp
1018

Sure.

1032

It absolutely could. I was trying to keep the code separate to make it standalone, but I can merge if you'd prefer.

1048

It's required for correctness. Consider a self referential phi node. You only want to add it to the worklist if you modify it, otherwise the loop would run forever.

Oh, wait, you were proposing a separate Visited structure. Yes, that would work. Do you have a preference?

1057

I don't think this would ever happen in practice, but it's theoretically sound to do.

sanjoy accepted this revision.Aug 17 2015, 10:57 AM
sanjoy edited edge metadata.

lgtm with comments addressed.

lib/Transforms/Scalar/RewriteStatepointsForGC.cpp
1032

I'd prefer that -- it makes it more obvious what happened.

1048

Do you have a preference?

No, I was just trying to make sure I understood what was going on. :)

This revision is now accepted and ready to land.Aug 17 2015, 10:57 AM
reames added inline comments.Aug 26 2015, 5:25 PM
lib/Transforms/Scalar/RewriteStatepointsForGC.cpp
1032

I spoke with Sanjoy offline. We convinced ourselves that tracking all the new instructions was actually more complex than the current patch, so I'm going ahead with the current scheme.

Two options which might be worth exploring in the future:

  • Using a custom IR builder with an insertion callback as InstCombine does. We'd have to be a bit careful here since we purposely have partially constructed phis/selects.
  • Switch the states map to being entirely bi-directional and maintain that all the way through.
This revision was automatically updated to reflect the committed changes.