On Sat, Mar 28, 2020 at 6:42 AM Richard Sandiford
<richard.sandif...@arm.com> wrote:
>
> David Edelsohn via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> > This patch is for an AIX problem, but the only robust solution is in
> > common code: calls.c:precompute_register_parameters().
> >
> > AIX, like other platforms, needs to call a function to obtain the
> > pointer to thread-local storage. If the thread local variable is
> > referenced as a parameter to a function call, the TLS resolution call
> > may clobber parameters to the primary function call.
> >
> > GCC calls.c has special provisions for this situation in
> > precompute_register_parameters, which tests each parameters with the
> > legitimate_constant_p target hook. Most targets define that hook to
> > return False for a TLS symbol.
> >
> > From the very initial implementation of the rs6000 port, Richard
> > Kenner utilized the GCC constant pool for the TOC managed by the
> > compiler -- the table of position independent pointers to global
> > symbols (like GOT). TLS symbols must be referenced by the TOC like
> > all global symbols and must be considered constants valid for the
> > constant pool.
>
> The way the hooks are set up,
>
> - legitimate_constant_p tests whether a constant is a legitimate
> immediate operand for insns
>
> - cannot_force_const_mem tests (in the negative) whether a constant
> is legitimate for the constant pool
>
> It's common for legitimate_constant_p to return false for constants that
> are valid for the constant pool.
>
> > Currently targetm.legitimate_constant_p() returns True for TLS symbols
> > on AIX, which inhibits the pre-legitimization of the TLS symbol in
> > calls.c and registers can be overridden. If the AIX port defines TLS
> > symbols as non-constant, emit_move_insn() prematurely calls
> > force_const_mem() and prevents the correct TLS and TOC code
> > generation.
> >
> > I have experimented extensively with attempts to have it both ways and
> > teach cannot_force_const_mem hook to reject TLS symbols during the
> > appropriate phases. This has proven too fragile a solution that
> > causes additional testsuite failures. targetm.legitimate_constant_p
> > has too many meanings and too many uses.
>
> This set-up sounds similar to many ELF targets. The approach there is that:
>
> (1) the TLS constant itself -- i.e. the actual runtime address for the
> current thread -- is not legitimate_constant_p
>
> (2) the TLS constant itself satisfies cannot_force_const_mem (i.e. can't
> go into the constant pool)
>
> (1) stops the constant reappearing in places that can't safely compute it
> (like the call case here). (2) is necessary because TLS constants,
> being thread-specific, are fundamentally not load-time constants.
>
> (1) + (2) together mean that the constant goes through the move expanders
> even though it's not a legitimate constant. (In some ways that's a bit
> of a hack, although not a bad one IMO.) The move expanders then reduce
> the constant to individual pieces. One of those pieces might be something
> that goes in the constant pool, with a TLS relocation applied to it.
>
> I'm probably well off the mark here, but it looks like the problem for
> AIX might be that it tries to force the TLS constant itself into the
> constant pool, rather than a piece of it. The structure is:
>
> static rtx
> rs6000_legitimize_tls_address_aix (rtx addr, enum tls_model model)
> {
> rtx sym, mem, tocref, tlsreg, tmpreg, dest, tlsaddr;
> const char *name;
> char *tlsname;
>
> name = XSTR (addr, 0);
> /* Append TLS CSECT qualifier, unless the symbol already is qualified
> or the symbol will be in TLS private data section. */
> if (name[strlen (name) - 1] != ']'
> && (TREE_PUBLIC (SYMBOL_REF_DECL (addr))
> || bss_initializer_p (SYMBOL_REF_DECL (addr))))
> ...create tlsaddr with a CSECT qualifier...;
> else
> tlsaddr = addr;
>
> /* Place addr into TOC constant pool. */
> sym = force_const_mem (GET_MODE (tlsaddr), tlsaddr);
>
> At this point we're forcing the original TLS constant into memory,
> i.e. the thread-specific runtime value that we're trying to compute.
>
> /* Output the TOC entry and create the MEM referencing the value. */
> if (constant_pool_expr_p (XEXP (sym, 0))
> && ASM_OUTPUT_SPECIAL_POOL_ENTRY_P (get_pool_constant (XEXP (sym,
> 0)), Pmode))
> {
> tocref = create_TOC_reference (XEXP (sym, 0), NULL_RTX);
> mem = gen_const_mem (Pmode, tocref);
> set_mem_alias_set (mem, get_TOC_alias_set ());
> }
> else
> return sym;
>
> I don't understand what the "return sym" case is handling, but it looks
> like that is the only time that the constant forced to memory above is
> the actual TLS constant. Down here...
The entire rhythm is exactly the same as rs6000_legitimize_address for
the creating a normal TOC entry. If it's a valid symbol but not yet
in the constant pool, it converts it to a TOC reference, otherwise it
returns the previously re-written symbol that already is in the
constant pool (TOC).
>
> /* Use global-dynamic for local-dynamic. */
> if (model == TLS_MODEL_GLOBAL_DYNAMIC
> || model == TLS_MODEL_LOCAL_DYNAMIC)
> {
> ...use the tocref with tls_get_addr[sd]i...
> return dest;
> }
> /* Obtain TLS pointer: 32 bit call or 64 bit GPR 13. */
> else if (TARGET_32BIT)
> {
> tlsreg = gen_reg_rtx (SImode);
> emit_insn (gen_tls_get_tpointer (tlsreg));
> }
> else
> tlsreg = gen_rtx_REG (DImode, 13);
>
> /* Load the TOC value into temporary register. */
> tmpreg = gen_reg_rtx (Pmode);
> emit_insn (gen_rtx_SET (tmpreg, mem));
> set_unique_reg_note (get_last_insn (), REG_EQUAL,
> gen_rtx_MINUS (Pmode, addr, tlsreg));
>
> /* Add TOC symbol value to TLS pointer. */
> dest = force_reg (Pmode, gen_rtx_PLUS (Pmode, tmpreg, tlsreg));
>
> return dest;
>
> ...we use "mem"/"tocref" as one piece of a larger calculation.
> I.e. the value in "mem"/"tocref" is just an input to the calculation,
> rather than the full result.
>
> On ELF targets, the usual way of handling this to use:
>
> (const (unspec [SYM] UNSPEC_SOME_TLS_RELOC))
>
> for the constant pieces of the TLS calculation. That const unspec is
> then a legitimate constant and/or a legitimate constant pool entry,
> even though the TLS constant itself isn't.
>
> So it looks like in the non-"return sym" case, the value being forced
> to memory should be some kind of unspec wrapper around the constant,
> instead of being the constant itself.
I realize that is how TLS for ELF is implemented in GCC and I realize
that GCC mostly is targeted at Linux/ELF. The support for AIX XCOFF
exists in GCC and functions. There is only so much that I can contort
XCOFF to look like ELF without completely re-writing TOC support,
which I'm not going to do. I'm trying to find the minimally invasive
solution for the TLS problem for AIX.
AIX XCOFF is not ELF. AIX does not emit instructions referencing
symbols with special decorations for the assembler and linker to
manage the GOT and relocations.
TLS on AIX creates additional, special TOC entries and appends
decorations to the symbol placed in the TOC (the GCC constant pool).
Frequently a GCC UNSPEC would be used to match a different pattern,
but for AIX it's a normal load of a symbol from the TOC.
.toc
LC..1:
.tc result.2299[TC],result.2299[UL]
LCM..1:
.tc .result.2299[TC],result.2299[UL]@m
...
lwz 3,LCM..1(2)
lwz 4,LC..1(2)
bla __tls_get_addr
How does wrapping the TLS symbol in an UNSPEC help? I'm not expecting
you to remember how the TOC works on AIX or the peculiarities of the
way that it is implemented in GCC, but your advice seems to ignore the
infrastructure for the support of non-TLS TOC symbols in GCC.
You are suggesting using the UNSPEC to flag a legitimized TLS symbol
versus a non-legitimized TLS symbol, and a legitimized TLS symbol is a
constant?
I'm trying to solve the narrow problem of a bug in TLS support without
re-writing the entire TOC implementation.
Thanks, David
