[PATCH] Reverse order in which base and derived pointers are lowered in the statepoint StackMap section

Philip Reames listmail at philipreames.com
Mon May 11 13:22:17 PDT 2015


REPOSITORY
  rL LLVM

================
Comment at: test/CodeGen/X86/statepoint-stackmap-format.ll:11
@@ -10,2 +10,3 @@
 
-define i1 @test(i32 addrspace(1)* %ptr) gc "statepoint-example" {
+define i1 @test(i32 addrspace(1)* %ptr_base, i32 addrspace(1)* %ptr_derived)
+  gc "statepoint-example" {
----------------
igor-laevsky wrote:
> reames wrote:
> > This is an invalid test.  An argument can not be a derived pointer.  This is currently utterly unsupported.  
> > 
> > You should create ptr_derived by bitcasting or gepping from the existing argument.  
> I fixed this test, but I am still not clear what do you mean by unsupported? It is true that in code generated with RewriteStatepointForGC pass we can not have such derived pointers. But from the lowering standpoint it does not make any difference how derived pointer were made. Also from the quick glance at the documentation I have not found that such cases are not supported. What am I missing?
> 
Hm, you're completely right here.  I was confusing what RewriteStatepointsForGC knows how to handle with what the lowering code is required to handle.  There's no reason the lowering code shouldn't handle this case correctly.

Can you add another test (copying what you had originally is fine) with a comment that explicitly says that?  If I or someone else try to implement something under my broken assumption above, it would be good to have a test case to catch that.

http://reviews.llvm.org/D9527

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






More information about the llvm-commits mailing list