[PATCH] Lower invoke statepoints and gc.results tied to them.

Philip Reames listmail at philipreames.com
Thu Feb 26 15:14:08 PST 2015


Summary of offline conversation.


REPOSITORY
  rL LLVM

================
Comment at: lib/CodeGen/SelectionDAG/StatepointLowering.cpp:257
@@ +256,3 @@
+      // so we need to export it now.
+      unsigned reg = Builder.FuncInfo.CreateRegs(Tmp->getType());
+      Builder.CopyValueToVirtualRegister(Tmp, reg);
----------------
igor-laevsky wrote:
> reames wrote:
> > I'm still confused about why we need this.  Why doesn't the standard export mechanism work here?  Simply producing the value and letting it be exported normally seems like it would work?
> Main problem here is that value we want to export is 'Tmp' which will be deleted few lines later. Therefore we need to export statepoint call itself, but it has different type than the actual call. Default mechanism for exporting values from BasicBlock calculates type of the register from Value* we are trying to export. So we need to create register with correct type manually. 
> 
> This probably could be wrapped in a helper function or an overload of a 'ExportFromCurrentBlock(Value*)' but it's the only place such problem appears so probably not worth it.
> 
> I have added comment describing this.
Igor and I talked about this a bit offline.  We realized that the heart of the issue here is that we need to export a value whose type does not match the type of the instruction it's associated with.  This is a "feature" unique to gc.statepoint.

We think the same issue can be replicated with:
  %token = call i32 gc.statepoint....
  br label %next

next:
  %res = call float gc.result(%token) 

Igor is going to investigate and see what it would take to have the export mechanism just handle this case directly.

An alternate approach would be to remove gc.result entirely and just use the result value (if there is one) as the token for gc.result.  We could introduce an artificial i32 return when the underlying function has a void return.  This may be a better long term approach, but is more churn than we'd prefer right now.

http://reviews.llvm.org/D7760

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






More information about the llvm-commits mailing list