Problems with addrspace(256) = GS in x86 codegen

[lattner]

Bugzilla Link	3966
Resolution	FIXED
Resolved on	Dec 02, 2010 01:41
Version	trunk
OS	All
CC	@asl,@sunfishcode,@nelhage

Extended Description

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

[sunfishcode]

There's a basic difference between TLS and your "256" feature.
TLS requires special handling for address leaf values only. With this
"256" feature, the %gs value is effectively added immediately for each
load or store (root values).

If you want these to share code, you might make X86ISelLowering do
Custom lowering for ISD::LOAD and ISD::STORE to insert an add of a
SegmentBaseAddress node to addresses as needed. That way they
would go through selection the same way.

Another thing to be aware of is that address space information is
carried by MachineMemOperand information, which isn't always
complete. It's easy to fix cases that are missing once they are found
though.

[lattner]

*** Bug llvm/llvm-bugzilla-archive#6698 has been marked as a duplicate of this bug. ***

[lattner]

I fixed this awhile ago.

[lattner]

mentioned in issue llvm/llvm-bugzilla-archive#6698