[PATCH] D13491: [RS4GC] Refactoring to make a later change easier, NFCI
Philip Reames via llvm-commits
llvm-commits at lists.llvm.org
Thu Oct 8 09:48:04 PDT 2015
reames accepted this revision.
reames added a comment.
This revision is now accepted and ready to land.
LGTM w/comments addressed.
================
Comment at: lib/Transforms/Scalar/RewriteStatepointsForGC.cpp:1354
@@ -1357,6 +1353,3 @@
- // Copy all of the arguments from the original statepoint - this includes the
- // target, call args, and deopt args
- SmallVector<llvm::Value *, 64> Args;
- Args.insert(Args.end(), CS.arg_begin(), CS.arg_end());
- // TODO: Clear the 'needs rewrite' flag
+ Statepoint SP(CS);
+
----------------
For clarity, I might call this OldSP.
================
Comment at: lib/Transforms/Scalar/RewriteStatepointsForGC.cpp:1357
@@ +1356,3 @@
+ ArrayRef<Value *> GCArgs(LiveVariables);
+ uint64_t StatepointID = SP.getID();
+ uint32_t NumPatchBytes = SP.getNumPatchBytes();
----------------
const?
================
Comment at: lib/Transforms/Scalar/RewriteStatepointsForGC.cpp:1359
@@ -1363,1 +1358,3 @@
+ uint32_t NumPatchBytes = SP.getNumPatchBytes();
+ StatepointFlags Flags = StatepointFlags(SP.getFlags());
----------------
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.
================
Comment at: lib/Transforms/Scalar/RewriteStatepointsForGC.cpp:1374
@@ +1373,3 @@
+ StatepointID, NumPatchBytes, CallTarget, Flags, CallArgs,
+ TransitionArgs, DeoptArgs, GCArgs, "safepoint_token");
+
----------------
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.
================
Comment at: test/Transforms/RewriteStatepointsForGC/relocation.ll:97
@@ -96,3 +96,3 @@
; CHECK-DAG: [ %arg.relocated, %if_branch ]
-; CHECK-DAG: [ %arg.relocated4, %else_branch ]
+; CHECK-DAG: [ %arg.relocated3, %else_branch ]
; CHECK-NOT: phi
----------------
I'm not seeing why this changed? Is this a non-determinism? Or did something in your patch effect ordering?
http://reviews.llvm.org/D13491
More information about the llvm-commits
mailing list