[PATCH] [GC] CodeGenPrep transform: simplify offsetable relocate

Ramkumar Ramachandra artagnon at gmail.com
Fri Jan 9 15:06:08 PST 2015


Oh, oops: I just realized that a User of a statepoint may be a gc.result: I'll adjust that in the next iteration.


================
Comment at: lib/CodeGen/CodeGenPrepare.cpp:564
@@ +563,3 @@
+  // Assume that the first relocate in the basic block is relocating the base
+  // object. TODO: what can be done to get rid of this assumption?
+  IntrinsicInst *MasterRelocate = RelocateCalls[0];
----------------
sanjoy wrote:
> reames wrote:
> > sanjoy wrote:
> > > This seems limiting, but correct; and a strict improvement over what we have.  We could easily have a `DenseMap<CallInst *, CallInst *>` that we build in a first pass that maps derived gc relocates to base gc relocates; and write the rest of the algorithm in terms of that.
> > Er, maybe I'm misreading Sanjoy's comment, but I think his first sentence is wrong.  There is no guarantee that the first gc.relocate encountered is a base relocation,
> > There is no guarantee that the first gc.relocate encountered is a base relocation,
> 
> I agree.  What I meant was that if the first `gc.relocate` is not a base relocation, then the worst case scenario is that we will miss the optimization, because that fact is checked later.
Is DenseMap<InstrinsicInst *, SmallVector<User *, 2>> more like what we want?

http://reviews.llvm.org/D6883

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






More information about the llvm-commits mailing list