[LLVMbugs] [Bug 13438] New: X86 slow instruction selector incorrectly folds FS- and GS-relative loads

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Mon Jul 23 12:52:05 PDT 2012


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

             Bug #: 13438
           Summary: X86 slow instruction selector incorrectly folds FS-
                    and GS-relative loads
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: csdavec at swan.ac.uk
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The following IR generates the correct asm with the fast register allocator,
but incorrect asm with the slow instruction selector:

%struct.thread = type { i32, i32, i32, i32 }

define i32 @test() nounwind uwtable {
  %1 = load volatile %struct.thread* addrspace(256)* null
  %2 = getelementptr inbounds %struct.thread* %1, i64 0, i32 2
  %3 = load i32* %2, align 4, !tbaa !3
  ret i32 %3
}

I have verified that this is not modified during optimisation with llc
-print-after-all.  With llc -O0, the following code is produced:


    movq    %gs:0, %rax
    movl    8(%rax), %eax
    ret

Note that the gs-relative load occurs first (as in the IR) and then the
resulting pointer is used in arithmetic.  In contrast, the following is
generated at -O1:

    movq    %gs:0, %rax
    movl    %gs:8, %eax
    ret

Ignoring the fact that this generates a redundant load, the second load is
incorrect.  This would only be a valid transform if the base of the GS segment
is at linear address 0 (in which case there is no point using gs-relative
addressing anyway). 

Substitute address space 257 for 267 and exactly the same bug occurs with
FS-relative addressing.

-- 
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