public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jiong Wang <jiong.wang@foss.arm.com>
To: Marcus Shawcroft <Marcus.Shawcroft@arm.com>
Cc: James Greenhalgh <james.greenhalgh@arm.com>,
	Richard Earnshaw <Richard.Earnshaw@foss.arm.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>
Subject: [Ping^2][AArch64][TLSGD][2/2] Implement TLS GD traditional for tiny code model
Date: Thu, 03 Dec 2015 10:42:00 -0000	[thread overview]
Message-ID: <56601C7F.6060904@foss.arm.com> (raw)
In-Reply-To: <56460013.2090403@foss.arm.com>

On 13/11/15 15:21, Jiong Wang wrote:
>
> On 05/11/15 14:57, Jiong Wang wrote:
>> Marcus Shawcroft writes:
>>
>>> +#ifdef HAVE_AS_TINY_TLSGD_RELOCS
>>> +  return SYMBOL_TINY_TLSGD;
>>> +#else
>>> +  return SYMBOL_SMALL_TLSGD;
>>> +#endif
>>>
>>> Rather than introduce blocks of conditional compilation it is better
>>> to gate different behaviours with a test on a constant expression. In
>>> this case add something like this:
>>>
>>> #if define(HAVE_AS_TINY_TLSGD_RELOCS)
>>> #define USE_TINY_TLSGD 1
>>> #else
>>> #define USE_TINY_TLSGD 0
>>> #endif
>>>
>>> up near the definition of TARGET_HAVE_TLS then write the above
>>> fragment without using the preprocessor:
>>>
>>> return USE_TINY_TLSGD ? SYMBOL_TINY_TLSGD : SYMBOL_SMALL_TLSGD;
>>
>> Done.
>>
>>> - aarch64_emit_call_insn (gen_tlsgd_small (result, imm, resolver));
>>> + if (type == SYMBOL_SMALL_TLSGD)
>>> +  aarch64_emit_call_insn (gen_tlsgd_small (result, imm, resolver));
>>> + else
>>> +  aarch64_emit_call_insn (gen_tlsgd_tiny (result, imm, resolver));
>>>   insns = get_insns ();
>>>   end_sequence ();
>>>
>>> Add a separate case statment for SYMBOL_TINY_TLSGD rather than reusing
>>> the case statement for SYMBOL_SMALL_TLSGD and then needing to add
>>> another test against symbol type within the body of the case
>>> statement.
>>
>> Done.
>>
>>>
>>> +(define_insn "tlsgd_tiny"
>>> +  [(set (match_operand 0 "register_operand" "")
>>> + (call (mem:DI (match_operand:DI 2 "" "")) (const_int 1)))
>>> +   (unspec:DI [(match_operand:DI 1 "aarch64_valid_symref" "S")]
>>> UNSPEC_GOTTINYTLS)
>>> +   (clobber (reg:DI LR_REGNUM))
>>> +  ]
>>> +  ""
>>> +  "adr\tx0, %A1;bl\t%2;nop";
>>> +  [(set_attr "type" "multiple")
>>> +   (set_attr "length" "12")])
>>>
>>> I don't think the explicit clobber LR_REGNUM is required since your
>>> change last September:
>>> https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02654.html
>>
>> We don't need this explict clobber LR_REGNUM only if operand 0 happen
>> be allocated to LR_REGNUM as after my above patch LR_REGNUM is 
>> allocable.
>>
>> However we still need the explict clobber here.  Because for all other
>> cases LR_REGNUM not allocated, gcc data flow analysis can't deduct 
>> LR_REGNUM
>> will still be clobbered implicitly by the call instruction.
>>
>> Without this "clobber" tag, a direct impact is df_regs_ever_live is 
>> calculated
>> incorrectly for x30, then for the following simple testcase:
>>
>> __thread int t0 = 0x10;
>> __thread int t1 = 0x10;
>>
>> int
>> main (int argc, char **argv)
>> {
>>   if (t0 != t1)
>>     return 1;
>>   return  0;
>> }
>>
>>
>> if you compile with
>>
>>  "-O2 -ftls-model=global-dynamic -fpic -mtls-dialect=trad t.c 
>> -mcmodel=tiny -fomit-frame-pointer",
>> wrong code will be generated:
>>
>>  main:
>>         str     x19, [sp, -16]!  <--- x30 is not saved.
>>         adr     x0, :tlsgd:t0
>>         bl __tls_get_addr
>>         nop
>>
>> Patch updated. tls regression OK
>>
>> OK for trunk?
>>
>> 2015-11-05  Jiong Wang  <jiong.wang@arm.com>
>>
>> gcc/
>>   * configure.ac: Add check for binutils global dynamic tiny code model
>>   relocation support.
>>   * configure: Regenerate.
>>   * config.in: Regenerate.
>>   * config/aarch64/aarch64.md (tlsgd_tiny): New define_insn.
>>   * config/aarch64/aarch64-protos.h (aarch64_symbol_type): New
>>   enumeration SYMBOL_TINY_TLSGD.
>>   (aarch64_symbol_context): New comment on SYMBOL_TINY_TLSGD.
>>   * config/aarch64/aarch64.c (aarch64_classify_tls_symbol): Support
>>   SYMBOL_TINY_TLSGD.
>>   (aarch64_print_operand): Likewise.
>>   (aarch64_expand_mov_immediate): Likewise.
>>   (aarch64_load_symref_appropriately): Likewise.
>>
>> gcc/testsuite/
>>   * lib/target-supports.exp (check_effective_target_aarch64_tlsgdtiny):
>>   New effective check.
>>   * gcc.target/aarch64/tlsgd_small_1.c: New testcase.
>>   * gcc.target/aarch64/tlsgd_small_ilp32_1.c: Likewise.
>>   * gcc.target/aarch64/tlsgd_tiny_1.c: Likewise.
>>   * gcc.target/aarch64/tlsgd_tiny_ilp32_1.c: Likewise.
> Ping ~

Ping^2

  reply	other threads:[~2015-12-03 10:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-19 14:59 [AArch64][TLSGD Trad][1/2] Generalize TLS Global Dynamic support for all memory mode Jiong Wang
2015-08-27  9:55 ` [AArch64][TLSGD][1/2] Remove unncessary define_expand for TLS GD traditional Jiong Wang
2015-08-27 10:04   ` [AArch64][TLSGD][2/2] Implement TLS GD traditional for tiny code model Jiong Wang
2015-10-06 13:32     ` Marcus Shawcroft
2015-11-05 14:57       ` Jiong Wang
2015-11-13 15:22         ` Jiong Wang
2015-12-03 10:42           ` Jiong Wang [this message]
2015-10-06 11:40   ` [AArch64][TLSGD][1/2] Remove unncessary define_expand for TLS GD traditional Marcus Shawcroft

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56601C7F.6060904@foss.arm.com \
    --to=jiong.wang@foss.arm.com \
    --cc=Marcus.Shawcroft@arm.com \
    --cc=Richard.Earnshaw@foss.arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=james.greenhalgh@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).