[PATCH] [Inliner][NFCI] Add an InlineSite abstraction.

Sanjoy Das sanjoy at playingwithpointers.com
Wed Jun 24 12:08:48 PDT 2015


================
Comment at: lib/Transforms/Utils/InlineFunction.cpp:66
@@ -65,1 +65,3 @@
 namespace {
+class InlineSite {
+  Function *CalledFunction;
----------------
reames wrote:
> I'm not convinced of the need for a new abstraction here.  What does this really add over having a function which takes a call site and extracts the underlying callee from a statepoint and the surface callee from a normal call?  An getUnwrappedCallee(CallSite CS) function seems to serve the same purpose with much less complexity.
> 
> Even if I accept the need for an extra abstraction, I *strongly* object to the duplication of the underlying fields.  Add proxying access if needed, but please do not duplicate each field from the underlying call site.
> What does this really add over having a function which takes a call site and extracts the underlying callee from a statepoint and the surface callee from a normal call?

It is not just the call destination -- I will have to update all of the places where the Inliner accesses, say, paramHasAttr and change it to do something different if the call site is a statepoint.  I suppose I could have a `getUnwrappedXXX` for each of those properties, but that's semantically what this class is.  Plus by having a separate type I can verify that I've not accidentally used `CS.getFoo()` where it would be incorrect to do so.

> Even if I accept the need for an extra abstraction, I *strongly* object to the duplication of the underlying fields. Add proxying access if needed, but please do not duplicate each field from the underlying call site.

Ok.

================
Comment at: lib/Transforms/Utils/InlineFunction.cpp:131
@@ +130,3 @@
+
+  Instruction *TheCall = CS.getInstruction();
+  if (!TheCall->use_empty()) {
----------------
reames wrote:
> I'm confused by this bit.  It seems like possibly an unrelated refactoring?  Or is this the statepoint related bits for gc.result?
I moved this part so to that I could RAUW `gc_result` easily in the following patch.  I'll split this bit out into its own refactoring.

================
Comment at: lib/Transforms/Utils/InlineFunction.cpp:1367
@@ -1264,13 +1366,3 @@
 
-    // If the return instruction returned a value, replace uses of the call with
-    // uses of the returned value.
-    if (!TheCall->use_empty()) {
-      ReturnInst *R = Returns[0];
-      if (TheCall == R->getReturnValue())
-        TheCall->replaceAllUsesWith(UndefValue::get(TheCall->getType()));
-      else
-        TheCall->replaceAllUsesWith(R->getReturnValue());
-    }
-    // Since we are now done with the Call/Invoke, we can delete it.
-    TheCall->eraseFromParent();
+    ReturnVal = Returns[0]->getReturnValue();
 
----------------
reames wrote:
> Unintentional diff?
See previous comment.

http://reviews.llvm.org/D10631

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list