This is an archive of the discontinued LLVM Phabricator instance.

[RS4GC] Refactoring to make a later change easier, NFCI
ClosedPublic

Authored by sanjoy on Oct 6 2015, 5:39 PM.

Details

Summary

These non-semantic changes will help make a later change adding
support for deopt operand bundles more streamlined.

Diff Detail

Repository
rL LLVM

Event Timeline

sanjoy updated this revision to Diff 36691.Oct 6 2015, 5:39 PM
sanjoy retitled this revision from to [RS4GC] Refactoring to make a later change easier, NFCI.
sanjoy updated this object.
sanjoy added reviewers: reames, swaroop.sridhar.
sanjoy added a subscriber: llvm-commits.
sanjoy updated this object.Oct 6 2015, 5:48 PM
reames accepted this revision.Oct 8 2015, 9:48 AM
reames edited edge metadata.

LGTM w/comments addressed.

lib/Transforms/Scalar/RewriteStatepointsForGC.cpp
1354 ↗(On Diff #36691)

For clarity, I might call this OldSP.

1357 ↗(On Diff #36691)

const?

1359 ↗(On Diff #36691)

This doesn't look right. You're converting a bitfield to an emum representing what the bits mean. I think you want the full bitfield.

1374 ↗(On Diff #36691)

In a separate change, might be better to use the name of the original statepoint. That will cause test churn, so please do separately if at all.

test/Transforms/RewriteStatepointsForGC/relocation.ll
97 ↗(On Diff #36691)

I'm not seeing why this changed? Is this a non-determinism? Or did something in your patch effect ordering?

This revision is now accepted and ready to land.Oct 8 2015, 9:48 AM
sanjoy marked 2 inline comments as done.Oct 8 2015, 3:55 PM
sanjoy added inline comments.
lib/Transforms/Scalar/RewriteStatepointsForGC.cpp
1357 ↗(On Diff #36691)

I'd then have to remove the const in the later semantic patch, which would make that diff larger.

test/Transforms/RewriteStatepointsForGC/relocation.ll
97 ↗(On Diff #36691)

It looks like there is a "semantic" change in this refactoring. I'm
not a 100% confident that I understand what's going on, but it looks
like CreateGCStatepointCall creates a named call instruction and
then inserts the said call instruction, whereas CreateCall
creates a nameless instruction, inserts it, and then calls setName
on it. This changes the number of times LastUnique is incremented
for the Function s ValueSymbolTable because calling setName on
an unattached instruction does not update the symbol table (since
there is no symbol table to update).

This does not really matter though -- only the stringified name is
affected, the bits of IR that matter should remain the same.

This revision was automatically updated to reflect the committed changes.