StackColoring::remapInstructions relies on GetUnderlyingObject to return the real underlying object in order to determine if an instruction needs to be remapped.

However GetUnderlyingObject does not always do so. In the particular case I was having trouble with, the underlying object was behind a ptrtoint which GetUnderlyingObject does not cross. For example line 06 below:

00 for.body.i:                                       ; preds = %for.body.i.lr.ph, %if.then.i.i.i.i
01   %14 = phi i32 [ %.ph32.i81, %for.body.i.lr.ph ], [ %inc.i.i.i.i, %if.then.i.i.i.i ]
02   %15 = bitcast i64* %retval.i.i to i32**
03   %16 = bitcast i64* %retval.i.i to i8*
04   call void @llvm.lifetime.start(i64 8, i8* %16)
05   store i32* %.ph.i80, i32** %15, align 8, !tbaa !0
06   %sunkaddr = ptrtoint i64* %retval.i.i to i32
07   %sunkaddr86 = add i32 %sunkaddr, 4
08   %sunkaddr87 = inttoptr i32 %sunkaddr86 to i32*
09   store i32 %14, i32* %sunkaddr87, align 4, !tbaa !3
10   %17 = load i64* %retval.i.i, align 8
11   call void @llvm.lifetime.end(i64 8, i8* %16)
12   %18 = lshr i64 %17, 32
13   %19 = trunc i64 %18 to i32
14   %shl.i.i.i = shl i32 1, %19
15   %20 = trunc i64 %17 to i32
16   br i1 %_Val, label %if.then.i.i, label %if.else.i.i


This results in incorrect alias information. Later in Machine Instruction Scheduling it seems as if updated and non-updated instructions are not aliased when indeed they are. In the example above the load on line 10 gets scheduled before the store in 09 which produces wrong results.