This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Ping: [RFA:] doc: TARGET_LEGITIMIZE_ADDRESS needs to be defined for native TLS
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: Tue, 29 May 2012 22:33:32 +0200
- Subject: Ping: [RFA:] doc: TARGET_LEGITIMIZE_ADDRESS needs to be defined for native TLS
> From: Hans-Peter Nilsson <hp@axis.com>
> Date: Wed, 16 May 2012 02:24:02 +0200
Ping...
> An old patch I finally came around to submit.
> Verified that the DVI and info output looks ok.
>
> Ok to commit with inherent relicensing and whatever?
>
> gcc:
> * doc/tm.texi.in (Addressing Modes) <TARGET_LEGITIMIZE_ADDRESS>:
> Mention that this hook needs to be defined for native TLS.
> * doc/tm.texi: Regenerate.
>
> Index: doc/tm.texi.in
> ===================================================================
> --- doc/tm.texi.in (revision 187568)
> +++ doc/tm.texi.in (working copy)
> @@ -5465,8 +5465,10 @@ The code of the hook should not alter th
> @var{x}. If it transforms @var{x} into a more legitimate form, it
> should return the new @var{x}.
>
> -It is not necessary for this hook to come up with a legitimate address.
> -The compiler has standard ways of doing so in all cases. In fact, it
> +It is not necessary for this hook to come up with a legitimate address,
> +with the exception of native TLS addresses (@pxref{Emulated TLS}).
> +The compiler has standard ways of doing so in all cases. In fact, if
> +the target supports only emulated TLS, it
> is safe to omit this hook or make it return @var{x} if it cannot find
> a valid way to legitimize the address. But often a machine-dependent
> strategy can generate better code.
>
> brgds, H-P
>