[LLVMbugs] [Bug 3966] New: Problems with addrspace(256) = GS in x86 codegen

[bugzilla-daemon at cs.uiuc.edu]

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

           Summary: Problems with addrspace(256) = GS in x86 codegen
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: miscompilation
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: rafael.espindola at gmail.com, llvmbugs at cs.uiuc.edu


The X86 backend almost has a cool feature where pointers with addrspace(256) is
a reference off the GS register.  Unfortunately, this has several problems:

1. No stores through GS are supported at all.
2. Not all loads to other address spaces properly indicate that they require
addrspace(0).

This means that we silently miscompile all stores through GS (bad) and many
loads.  For example, this code is miscompiled:

void foo() {
  int __attribute__((address_space(256))) *P = 1234;
  P[4] = 17;
}
void * bar(__attribute__((address_space(256))) unsigned long * const P) {
        if (P[4]) 
                P[5]++;
        return (void *)P[6];
}

Into:

_foo:
LBB1_0: ## entry
        movl    $17, 1250
        ret

_bar:
LBB2_0: ## entry
        movl    4(%esp), %eax
        movl    %gs:16(%eax), %ecx
        testl   %ecx, %ecx
        je      LBB2_2  ## if.end
LBB2_1: ## if.then
        addl    $1, 20(%eax)
LBB2_2: ## if.end
        movl    %gs:24(%eax), %eax
        ret

Note that the store in foo is not GS'ified, and the addl in LBB2_1 also lacks a
GS qualifier.

My hope is that Rafael's work just magically makes this all better :)


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