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: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: ubizjak at gmail dot com (Uros Bizjak)
- Cc: rth at redhat dot com (Richard Henderson), gcc-patches at gcc dot gnu dot org, hjl dot tools at gmail dot com (H.J. Lu)
- Date: Mon, 23 Apr 2012 17:27:54 +0200 (CEST)
- Subject: Re: [PATCH, i386]: FIX PR 52698, reload failure with complex address
Uros Bizjak wrote:
> On Tue, Mar 27, 2012 at 7:20 PM, Richard Henderson <firstname.lastname@example.org> wrote:
> > On 03/27/12 09:37, Uros Bizjak wrote:
> >>> > Now, in this particular case, there might be another option to
> >>> > avoid this hassle completely: =A0I understand that this UNSPEC is
> >>> > simply a magic marker to make the address use the fs: or gs:
> >>> > segment override, right? =A0 Now that GCC supports address spaces,
> >>> > it might be possible to model fs:/gs: relative addresses instead
> >>> > by using a non-standard address space ...
> >> This is an interesting idea, I will look into it.
> > Generallized segment overrides via non-standard address spaces
> > has been on my to-do list for quite a while...
> I have looked a bit to implement this functionality, but address
> spaces are somehow coupled with a keyword that describes special
> address space. I guess we can't just reuse __thread keyword for this
> 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.
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.
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
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE