On 04/23/12 08:27, Ulrich Weigand wrote: >> Ulrich, can you please provide some guidelines on how you think this >> proposed functionality should be implemented? > > Well, you do not *have* to have a keyword for a special address space. > > One possible implementation might be: > > - You define an address space number that refers to the fs: (or gs:) > segment. (Or probably better: *two* numbers, one refering to fs: > and the other to gs:) > > - You implement back-end support for accessing that address space number > (i.e. emitting the segment override prefix in patterns that accept > a MEM classified with that address space). > > - You *generate* MEMs using that address space number *internally*, e.g. > from within legitimize_tls_address to implement access to TLS variables.
It's not quite that simple. For TLS, we need to transform (mem (addr1) AS_GENERIC) to (mem (addr2) AS_FS) but targetm.addr_space.legitimize_address only gets addr1 + AS_GENERIC, and is only able to return addr2. > If you do that, you don't *need* a keyword just for TLS. You might want > to expose the address space externally anyway, e.g. to simplify things > for user space applications (like Wine) that themselves want to access memory > via segment overrides. In that case, I'd probably use keywords like > __fs > __gs > to refer to fs: / gs: relative addresses. I actually started on this about a week ago. Even this has a fair amount of interconnected-ness that's tricky to pick through. Given the above, I thought it would be a bit easier to start with __fs/__gs and then work backward, if you will. > In addition, you might want to implement something like a __far keyword > that refers to 48-bit pointers; this would require yet another address > space number to represent the full space of 48-bit pointers; accessing > a so-qualified MEM would require first loading the segment part into a > (free) segment register, and then using that register to perform the > access ... This is a _significantly_ harder prospect. For this you have to have reload allocate both a segment register and a general register in order to be able to implement the address. Given how ubiquitous 64-bit hosts are, I can think of no reasonable need for this. OTOH, there are programs like OpenGL that can make use of WR[FG]SBASE to manage "register allocation" of the segment registers by hand, and only require __[fg]s keywords within the compiler to make using the addresses easier. r~
