Re: [PATCH, i386]: FIX PR 52698, reload failure with complex address

[Richard Henderson <rth at redhat dot com>]

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~