This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, i386]: FIX PR 52698, reload failure with complex address
- From: Richard Henderson <rth at redhat dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Uros Bizjak <ubizjak at gmail dot com>, gcc-patches at gcc dot gnu dot org, "H.J. Lu" <hjl dot tools at gmail dot com>
- Date: Mon, 23 Apr 2012 13:23:08 -0700
- Subject: Re: [PATCH, i386]: FIX PR 52698, reload failure with complex address
- References: <201204231527.q3NFRshJ003822@d06av02.portsmouth.uk.ibm.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)
(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
> 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