[PATCH] [RewriteStatepointsForGC] Fix a bug on creating gc_relocate for pointer to vector of pointers

Chen Li meloli87 at gmail.com
Fri May 8 10:00:55 PDT 2015


================
Comment at: lib/CodeGen/CodeGenPrepare.cpp:627
@@ +626,3 @@
+    if (RelocatedBase->getType() != Base->getType()) {
+      ActualRelocatedBase =
+          cast<Instruction>(Builder.CreateBitCast(RelocatedBase, Base->getType()));
----------------
sanjoy wrote:
> Why not directly insert `ActualRelocatedBase` after `RelocatedBase` by something like:
> 
> ```
> if (...) {
>   IRBuilder::InsertPointGuard IPG(RelocatedBase->getNextNode());
>   Builder.CreateBitCast ...
> ```
I basically try to follow the existing code:


```
Value *Replacement = Builder.CreateGEP(
       Derived->getSourceElementType(), RelocatedBase, makeArrayRef(OffsetV));
Instruction *ReplacementInst = cast<Instruction>(Replacement);
ReplacementInst->removeFromParent();
ReplacementInst->insertAfter(RelocatedBase);
```

I wouldn't mind to use either of the styles, but I would prefer to do a separate patch if we need to change.

================
Comment at: lib/IR/Verifier.cpp:3365
@@ -3368,1 +3364,3 @@
+    // gc_relocate does not need to be the same type as the relocated pointer.
+    // It can casted to the correct type later if it's desired
     break;
----------------
sanjoy wrote:
> As a separate step, do you think it makes sense to erase the types of the pointers being relocated as well (when they're being fed into the `statepoint` call)?  We'll have to do something like that anyway once LLVM has a unified `ptr` pointer type.
I think we should do it if it follows LLVM's direction.

================
Comment at: lib/Transforms/InstCombine/InstCombineCalls.cpp:1212
@@ +1211,3 @@
+      // gc_relocate is uncasted. Use undef of gc_relocate's type to replace it.
+      return ReplaceInstUsesWith(*II, UndefValue::get(II->getType()));
+    }
----------------
sanjoy wrote:
> Maybe have a `auto *GCRelocateType = cast<PointerType>(II->getType());` hoisted out?
Will do

================
Comment at: lib/Transforms/Scalar/RewriteStatepointsForGC.cpp:1080
@@ +1079,3 @@
+    // cases where the actual value's type mangling is not supported by llvm. A
+    // bitcast is added later to convert gc_relocate to the actual value's type.
+    types.push_back(Type::getInt8PtrTy(M->getContext(), 1));
----------------
sanjoy wrote:
> As a separate change, does it make sense to get rid of gc relocates being type-polymorphic on its return type and just have one `gc_relocate` intrinsic.
That would make sense.

================
Comment at: lib/Transforms/Scalar/RewriteStatepointsForGC.cpp:1357
@@ +1356,3 @@
+    Instruction *valueToStore = nullptr;
+    // gc_relocate are just created and haven't been relocated yet. If it has
+    // no use, it means the actual relocated value's type is i8 addrspace(1)*
----------------
sanjoy wrote:
> Can we remove the bitcasting logic from `CreateGCRelocates` and unconditionally bitcast to the type of the alloca here?  I think that will simplify the logic.
Yes, that's a good idea. In that way only this method need to be touched.

http://reviews.llvm.org/D9592

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






More information about the llvm-commits mailing list