From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id 06DA83858D20 for ; Thu, 16 Nov 2023 01:07:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 06DA83858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 06DA83858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::635 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700096861; cv=none; b=xEB2dYiWkNkqYPx2P+BMnudzJfBLc6LusnXWH8I1a4Urp1b/CLR2LgdE3xl5QpH/6f0pVFaZG48YOqyqdhg5d0rTkqPZ8KdFZizwBEBjSKjrhCvalAXFRKbtp5jqng/g+68yK0gHYemo3vAirC83nhkx9Lgl+ecX1KN/2BhoJ/w= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700096861; c=relaxed/simple; bh=7X78F7njsfP7rGMmZxhTK2DiOm0CKWD7EawGaXuaUok=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=aNZzWZDHzA6ZoLx+J92/CDdLDiokSagci758vCy/9lw9LLFrOVx90SVf5C7OP8dpM2TGSqbiMW28OPbCEyOv19Fc1w0UwEMMlzkXb3tCbat6dK1obcQIvv1+YTTuVrVb8puRoNSZq9kqVN0qNglV5P9kektojYH7rI7HvbGYC5o= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x635.google.com with SMTP id d9443c01a7336-1cc3542e328so2678495ad.1 for ; Wed, 15 Nov 2023 17:07:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700096857; x=1700701657; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=nWQewUsGM4uZ7pc7qG2gPXbjAML8EN20S9k0mdM6Td8=; b=cTuKEfhrgtvJz1UEm3eoT+vBwjCFduDoOkqdEMUx/3ju2Ml84YSwytzDcCpGe/NDXh Z0UgkI70gRQ5PlrIU5oVlIN+rD0Ivkfz7r0DAh6+MG9YJ1rPz9rwm5D97+hEBfjF7BeH inBJyLvdzdjeYz01zUNadakSDOF4MDy9H25hDSgZ97V2j7KvAeDxkJ1DsU3q9hlq6RoV eVBST9jyAPtsPYGi13LEaChgXwY8hlMqw8YTgAzpVYksbG0ML+VfPU/Wt0DNHgtHHPsk DQ5zF3awA+hPOn6nvOnPf80HOs3TZQlR8o2FdLSk+vkfdQgZ6/8dfpIUsyNQ26Q+CMap nkiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700096857; x=1700701657; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nWQewUsGM4uZ7pc7qG2gPXbjAML8EN20S9k0mdM6Td8=; b=wOZT0PfMkXM76UsN6Ex2Fu0gkcN4uQ+ql+5EuJEjIujCAc0zdwUMovimDiDGp9OMrR JXQrTJtv+eaH9h3/bhfyU14rQ+JPeN9XCfBIJmWDoK+9VKq/G9RgKvK3ZVsBVHIp7cJg X/F+BszK69PNKTHKHCQYREdFMR6EJ6lO9igFF4DD+HPXaOoS5tTaw2zMqoXwx0saevBV EKKYTW0DzeRx9o+MNB3/adyo8K1QgMApIVv19Pg/ewl4G2oApZlv8r/kgJAnyYhnpSqd mX/al4JhZRjuKjHHsp23HFOTEOR9DyYflfTyHS8g9zb/ndiSchohE84QYpJx4fPCQk+c Zs4Q== X-Gm-Message-State: AOJu0YwDMF+W6IlDex9fnKWJMzhkRbzNyU3CzRdM1T+iQUzMfXu5lnrN rbT8UEMKVCLO1oaawSvcHcVueehLejTy2w== X-Google-Smtp-Source: AGHT+IGWz3z/53/SS36SDMpgiRzuxnmer4EQvWytMIPyRHCPD7WLRVZWpUqKlGCoL4j1Nw4p9Q8r0g== X-Received: by 2002:a17:902:bc4c:b0:1cc:bf63:930 with SMTP id t12-20020a170902bc4c00b001ccbf630930mr7496092plz.28.1700096857502; Wed, 15 Nov 2023 17:07:37 -0800 (PST) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id b2-20020a170902b60200b001c61901ed37sm7933249pls.191.2023.11.15.17.07.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Nov 2023 17:07:37 -0800 (PST) Message-ID: <54cba99d-fa53-4ecd-b850-f8f7e2c8a21a@gmail.com> Date: Wed, 15 Nov 2023 18:07:31 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] RISC-V: Implement TLS Descriptors. Content-Language: en-US To: Tatsuyuki Ishi Cc: gcc-patches@gcc.gnu.org, rui314@gmail.com, ruiu@bluewhale.systems, kito.cheng@gmail.com References: <20230817181308.122802-2-ishitatsuyuki@gmail.com> <20230908104923.31154-1-ishitatsuyuki@gmail.com> From: Jeff Law In-Reply-To: <20230908104923.31154-1-ishitatsuyuki@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_STOCKGEN,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,URIBL_BLACK autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 9/8/23 04:49, Tatsuyuki Ishi via Gcc-patches wrote: > This implements TLS Descriptors (TLSDESC) as specified in [1]. > > In TLSDESC instruction sequence, the first instruction relocates against > the target TLS variable, while subsequent instructions relocates against > the address of the first. Such usage of labels are not well-supported > within GCC. Due to this, the 4-instruction sequence is implemented as a > single RTX insn. > > The default remains to be the traditional TLS model, but can be configured > with --with_tls={trad,desc}. The choice can be revisited once toolchain > and libc support ships. > > [1]: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373. > > gcc/Changelog: > * config/riscv/riscv.opt: Add -mtls-dialect to configure TLS flavor. > * config.gcc: Add --with_tls configuration option to change the default > TLS flavor. > * config/riscv/riscv.h: Add TARGET_TLSDESC determined from > -mtls-dialect and with_tls defaults. > * config/riscv/riscv-opts.h: Define enum riscv_tls_type for the two TLS > flavors. > * config/riscv/riscv-protos.h: Define SYMBOL_TLSDESC symbol type. > * config/riscv/riscv.md: Add instruction sequence for TLSDESC. > * config/riscv/riscv.cc (riscv_symbol_insns): Add instruction sequence > length data for TLSDESC. > (riscv_legitimize_tls_address): Add lowering of TLSDESC. > --- > @@ -4694,6 +4696,17 @@ case "${target}" in > ;; > esac > fi > + # Handle --with-tls. > + case "$with_tls" in > + "" \ > + | trad | desc) > + # OK > + ;; > + *) > + echo "Unknown TLS method used in --with-tls=$with_tls" 1>&2 > + exit 1 > + ;; > + esac Is there a reason why this isn't formatted like the other cases? > @@ -1869,6 +1870,24 @@ > [(set_attr "got" "load") > (set_attr "mode" "")]) > > +(define_insn "@tlsdesc" > + [(set (reg:P A0_REGNUM) > + (unspec:P > + [(match_operand:P 0 "symbolic_operand" "") > + (match_operand:P 1 "const_int_operand")] > + UNSPEC_TLSDESC)) > + (clobber (reg:SI T0_REGNUM))] > + "TARGET_TLSDESC" > + { > + return ".LT%1: auipc\ta0, %%tlsdesc_hi(%0)\;" > + "\tt0,%%tlsdesc_load_lo(.LT%1)(a0)\;" > + "addi\ta0,a0,%%tlsdesc_add_lo(.LT%1)\;" > + "jalr\tt0,t0,%%tlsdesc_call(.LT%1)"; > + } > + [(set_attr "type" "multi") > + (set_attr "length" "16") > + (set_attr "mode" "")]) Hmm, I would be a bit worried about explicitly using $a0 here. That's generally frowned upon, but probably unavoidable in this case since this is a call under the hood. This needs changes to invoke.texi since it introduces new options. I don't think it has to be anything terribly verbose. A one liner is probably sufficient and I wouldn't be surprised if other ports have suitable text we could copy. So overall if Kito's OK, then I am with the trivial doc change and perhaps the formatting fix in config.guess. jeff