[LLVMbugs] [Bug 14090] New: StackColoring::remapInstructions does not remap all necessary instructions

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Mon Oct 15 13:42:43 PDT 2012


http://llvm.org/bugs/show_bug.cgi?id=14090

             Bug #: 14090
           Summary: StackColoring::remapInstructions does not remap all
                    necessary instructions
           Product: tools
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: opt
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: mcurtis at codeaurora.org
                CC: llvmbugs at cs.uiuc.edu, nrotem at apple.com
    Classification: Unclassified


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.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the llvm-bugs mailing list