[PATCH] Regenerate opt.urls

[Tatsuyuki Ishi]

Fixes: 97069657c4e ("RISC-V: Implement TLS Descriptors.")

gcc/ChangeLog:
* config/riscv/riscv.opt.urls: Regenerated.
---
 gcc/config/riscv/riscv.opt.urls | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/config/riscv/riscv.opt.urls b/gcc/config/riscv/riscv.opt.urls
index da31820e234..351f7f0dda2 100644
--- a/gcc/config/riscv/riscv.opt.urls
+++ b/gcc/config/riscv/riscv.opt.urls
@@ -89,3 +89,5 @@ UrlSuffix(gcc/RISC-V-Options.html#index-minline-strncmp)
 minline-strlen
 UrlSuffix(gcc/RISC-V-Options.html#index-minline-strlen)
 
+; skipping UrlSuffix for 'mtls-dialect=' due to finding no URLs
+
-- 
2.44.0

[PATCH v5] RISC-V: Implement TLS Descriptors.

[Tatsuyuki Ishi]

This implements TLS Descriptors (TLSDESC) as specified in [1].

The 4-instruction sequence is implemented as a single RTX insn for
simplicity, but this can be revisited later if instruction scheduling or
more flexible RA is desired.

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.
* doc/install.texi: Document --with-tls for RISC-V.
* doc/invoke.texi: Document -mtls-dialect for RISC-V.
* testsuite/gcc.target/riscv/tls_1.x: Add TLSDESC GD test case.
* testsuite/gcc.target/riscv/tlsdesc.c: Same as above.
---
No regression in gcc tests for rv32gcv and rv64gcv, tested alongside
the binutils and glibc implementation. Tested with --with-tls=desc.

v2: Add with_tls configuration option, and a few readability improvements.
Added Changelog.
v3: Add documentation per Kito's suggestion.
Fix minor issues pointed out by Kito and Jeff.
Thanks Kito Cheng and Jeff Law for review.
v4: Add TLSDESC GD assembly test.
Rebase on top of trunk.
v5: Trivial rebase on top of trunk.

I have recently addressed relaxation concerns on binutils and RVV
register save/restore on glibc, so I'm sending out a trivial rebase
with the hope that the full set can be merged soon.

 gcc/config.gcc   | 15 ++-
 gcc/config/riscv/riscv-opts.h|  6 ++
 gcc/config/riscv/riscv-protos.h  |  5 +++--
 gcc/config/riscv/riscv.cc| 24 
 gcc/config/riscv/riscv.h |  9 +++--
 gcc/config/riscv/riscv.md| 20 +++-
 gcc/config/riscv/riscv.opt   | 14 ++
 gcc/doc/install.texi |  3 +++
 gcc/doc/invoke.texi  | 13 -
 gcc/testsuite/gcc.target/riscv/tls_1.x   |  5 +
 gcc/testsuite/gcc.target/riscv/tlsdesc.c | 12 
 11 files changed, 115 insertions(+), 11 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/tls_1.x
 create mode 100644 gcc/testsuite/gcc.target/riscv/tlsdesc.c

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 17873ac2103..1a5870672d2 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2492,6 +2492,7 @@ riscv*-*-linux*)
# Force .init_array support.  The configure script cannot always
# automatically detect that GAS supports it, yet we require it.
gcc_cv_initfini_array=yes
+   with_tls=${with_tls:-trad}
;;
 riscv*-*-elf* | riscv*-*-rtems*)
tm_file="elfos.h newlib-stdint.h ${tm_file} riscv/elf.h"
@@ -2534,6 +2535,7 @@ riscv*-*-freebsd*)
# Force .init_array support.  The configure script cannot always
# automatically detect that GAS supports it, yet we require it.
gcc_cv_initfini_array=yes
+   with_tls=${with_tls:-trad}
;;
 
 loongarch*-*-linux*)
@@ -4671,7 +4673,7 @@ case "${target}" in
;;
 
riscv*-*-*)
-   supported_defaults="abi arch tune riscv_attribute isa_spec"
+   supported_defaults="abi arch tune riscv_attribute isa_spec tls"
 
case "${target}" in
riscv-* | riscv32*) xlen=32 ;;
@@ -4801,6 +4803,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
 
# Handle --with-multilib-list.
if test "x${with_multilib_list}" != xdefault; then
diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index 392b9169240..1b2dd5757a8 100644
--- a/gcc/config/riscv/riscv-opts.h
+++ b/gcc/config/riscv/riscv-opts.h
@@ -154,4 +154,10 @@ enum rvv_vector_bits_enum {
 #define TARGET_MAX_LMUL
\
   (int) (rvv_max_lmul 

Re: [PATCH v3] RISC-V: Implement TLS Descriptors.

[Tatsuyuki Ishi]

> On Nov 21, 2023, at 15:59, Fangrui Song  wrote:
> 
> On Mon, Nov 20, 2023 at 6:20 AM Tatsuyuki Ishi  <mailto:ishitatsuy...@gmail.com>> wrote:
>> 
>> This implements TLS Descriptors (TLSDESC) as specified in [1].
>> 
>> The 4-instruction sequence is implemented as a single RTX insn for
>> simplicity, but this can be revisited later if instruction scheduling or
>> more flexible RA is desired.
>> 
>> 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.
>>* doc/install.texi: Document --with-tls for RISC-V.
>>* doc/invoke.texi: Document --mtls-dialect for RISC-V.
> 
> Nit: One dash for --mtls-dialect.
> 
>> ---
>> No regression in gcc tests for rv64gc, tested alongside the binutils and
>> glibc implementation. Tested with --with_tls=desc.
>> 
>> v2: Add with_tls configuration option, and a few readability improvements.
>>Added Changelog.
>> v3: Add documentation per Kito's suggestion.
>>Fix minor issues pointed out by Kito and Jeff.
>>Thanks Kito Cheng and Jeff Law for review.
>> 
>> I've considered gating this behind a GAS feature test, but it seems
>> nontrivial especially for restricting the variants available at runtime.
>> Since TLS descriptors is not selected by default, I've decided to leave it
>> ungated.
>> 
>> In other news, I have made some progress on binutils side, and I'll try to
>> update the GAS / ld patch set with relaxation included, by the end of this
>> month.
> 
> Thanks for the update.  I understand the complexity adding a runtime
> test when the feature also requires binutils and rtld support.
> I hope that we add a test checking assembly under
> gcc/testsuite/gcc.target/riscv/tls , otherwise as a non-default test,
> when this breaks, it may be difficult to figure it out.
> (glibc/elf/tst-* will need a runtime test, but GCC needs to have its own.)
> 
>> gcc/config.gcc  | 15 ++-
>> gcc/config/riscv/riscv-opts.h   |  6 ++
>> gcc/config/riscv/riscv-protos.h |  5 +++--
>> gcc/config/riscv/riscv.cc   | 24 
>> gcc/config/riscv/riscv.h|  9 +++--
>> gcc/config/riscv/riscv.md   | 21 -
>> gcc/config/riscv/riscv.opt  | 14 ++
>> gcc/doc/install.texi|  3 +++
>> gcc/doc/invoke.texi | 13 -
>> 9 files changed, 99 insertions(+), 11 deletions(-)
>> 
>> diff --git a/gcc/config.gcc b/gcc/config.gcc
>> index 415e0e1ebc5..2c1a7179b02 100644
>> --- a/gcc/config.gcc
>> +++ b/gcc/config.gcc
>> @@ -2434,6 +2434,7 @@ riscv*-*-linux*)
>># Force .init_array support.  The configure script cannot always
>># automatically detect that GAS supports it, yet we require it.
>>gcc_cv_initfini_array=yes
>> +   with_tls=${with_tls:-trad}
>>;;
>> riscv*-*-elf* | riscv*-*-rtems*)
>>tm_file="elfos.h newlib-stdint.h ${tm_file} riscv/elf.h"
>> @@ -2476,6 +2477,7 @@ riscv*-*-freebsd*)
>># Force .init_array support.  The configure script cannot always
>># automatically detect that GAS supports it, yet we require it.
>>gcc_cv_initfini_array=yes
>> +   with_tls=${with_tls:-trad}
>>;;
>> 
>> loongarch*-*-linux*)
>> @@ -4566,7 +4568,7 @@ case "${target}" in
>>;;
>> 
>>riscv*-*-*)
>> -   supported_defaults="abi arch tune riscv_attribute isa_spec"
>> +   supported_defaults="abi arch tune r

[PATCH v4] RISC-V: Implement TLS Descriptors.

[Tatsuyuki Ishi]

This implements TLS Descriptors (TLSDESC) as specified in [1].

The 4-instruction sequence is implemented as a single RTX insn for
simplicity, but this can be revisited later if instruction scheduling or
more flexible RA is desired.

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.
* doc/install.texi: Document --with-tls for RISC-V.
* doc/invoke.texi: Document -mtls-dialect for RISC-V.
* testsuite/gcc.target/riscv/tls_1.x: Add TLSDESC GD test case.
* testsuite/gcc.target/riscv/tlsdesc.c: Same as above.
---
No regression in gcc tests for rv64gc, tested alongside the binutils and
glibc implementation. Tested with --with_tls=desc.

v2: Add with_tls configuration option, and a few readability improvements.
Added Changelog.
v3: Add documentation per Kito's suggestion.
Fix minor issues pointed out by Kito and Jeff.
Thanks Kito Cheng and Jeff Law for review.
v4: Add TLSDESC GD assembly test.
Rebase on top of trunk.

 gcc/config.gcc   | 15 ++-
 gcc/config/riscv/riscv-opts.h|  6 ++
 gcc/config/riscv/riscv-protos.h  |  5 +++--
 gcc/config/riscv/riscv.cc| 24 
 gcc/config/riscv/riscv.h |  9 +++--
 gcc/config/riscv/riscv.md| 20 +++-
 gcc/config/riscv/riscv.opt   | 14 ++
 gcc/doc/install.texi |  3 +++
 gcc/doc/invoke.texi  | 13 -
 gcc/testsuite/gcc.target/riscv/tls_1.x   |  5 +
 gcc/testsuite/gcc.target/riscv/tlsdesc.c | 12 
 11 files changed, 115 insertions(+), 11 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/tls_1.x
 create mode 100644 gcc/testsuite/gcc.target/riscv/tlsdesc.c

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 748430194f3..8bb22e9f590 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2490,6 +2490,7 @@ riscv*-*-linux*)
# Force .init_array support.  The configure script cannot always
# automatically detect that GAS supports it, yet we require it.
gcc_cv_initfini_array=yes
+   with_tls=${with_tls:-trad}
;;
 riscv*-*-elf* | riscv*-*-rtems*)
tm_file="elfos.h newlib-stdint.h ${tm_file} riscv/elf.h"
@@ -2532,6 +2533,7 @@ riscv*-*-freebsd*)
# Force .init_array support.  The configure script cannot always
# automatically detect that GAS supports it, yet we require it.
gcc_cv_initfini_array=yes
+   with_tls=${with_tls:-trad}
;;
 
 loongarch*-*-linux*)
@@ -4658,7 +4660,7 @@ case "${target}" in
;;
 
riscv*-*-*)
-   supported_defaults="abi arch tune riscv_attribute isa_spec"
+   supported_defaults="abi arch tune riscv_attribute isa_spec tls"
 
case "${target}" in
riscv-* | riscv32*) xlen=32 ;;
@@ -4788,6 +4790,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
 
# Handle --with-multilib-list.
if test "x${with_multilib_list}" != xdefault; then
diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index 30efebbf07b..b2551968be0 100644
--- a/gcc/config/riscv/riscv-opts.h
+++ b/gcc/config/riscv/riscv-opts.h
@@ -138,4 +138,10 @@ enum stringop_strategy_enum {
 #define TARGET_MAX_LMUL
\
   (int) (riscv_autovec_lmul == RVV_DYNAMIC ? RVV_M8 : riscv_autovec_lmul)
 
+/* TLS types.  */
+enum riscv_tls_type {
+  TLS_TRADITIONAL,
+  TLS_DESCRIPTORS
+};
+
 #endif /* ! GCC_RISCV_OPTS_H */
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/ri

Re: [PATCH v3] RISC-V: Implement TLS Descriptors.

[Tatsuyuki Ishi]

> On Nov 23, 2023, at 19:57, Florian Weimer  wrote:
> 
> * Tatsuyuki Ishi:
> 
>> I've considered gating this behind a GAS feature test, but it seems
>> nontrivial especially for restricting the variants available at runtime.
>> Since TLS descriptors is not selected by default, I've decided to leave it
>> ungated.
>> 
>> In other news, I have made some progress on binutils side, and I'll try to
>> update the GAS / ld patch set with relaxation included, by the end of this
>> month.
> 
> Is there a glibc patch with the run-time implementation already?
> 
> I'm curious how you are going to implement saving the vector register
> file

There is, please see [1].  The vector register file handling is missing right
now as I’m not sure if we have agreed upon a calling convention for RVV.

In the spec, I have already specified the interaction with RVV:

> Any other registers are callee-saved. This includes any vector registers
when the vector extension is supported.

Once the calling convention is decided, I will add saving of all caller-saved
registers into the TLSDESC stub.

[1]: 
https://inbox.sourceware.org/libc-alpha/20230914084033.222120-1-ishitatsuy...@gmail.com/

> Thanks,
> Florian
> 

Re: [PATCH v3] RISC-V: Implement TLS Descriptors.

[Tatsuyuki Ishi]

> On Nov 21, 2023, at 15:59, Fangrui Song  wrote:
> 
> On Mon, Nov 20, 2023 at 6:20 AM Tatsuyuki Ishi  <mailto:ishitatsuy...@gmail.com>> wrote:
>> 
>> This implements TLS Descriptors (TLSDESC) as specified in [1].
>> 
>> The 4-instruction sequence is implemented as a single RTX insn for
>> simplicity, but this can be revisited later if instruction scheduling or
>> more flexible RA is desired.
>> 
>> 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.
>>* doc/install.texi: Document --with-tls for RISC-V.
>>* doc/invoke.texi: Document --mtls-dialect for RISC-V.
> 
> Nit: One dash for --mtls-dialect.

Ack. Thanks.

>> ---
>> No regression in gcc tests for rv64gc, tested alongside the binutils and
>> glibc implementation. Tested with --with_tls=desc.
>> 
>> v2: Add with_tls configuration option, and a few readability improvements.
>>Added Changelog.
>> v3: Add documentation per Kito's suggestion.
>>Fix minor issues pointed out by Kito and Jeff.
>>Thanks Kito Cheng and Jeff Law for review.
>> 
>> I've considered gating this behind a GAS feature test, but it seems
>> nontrivial especially for restricting the variants available at runtime.
>> Since TLS descriptors is not selected by default, I've decided to leave it
>> ungated.
>> 
>> In other news, I have made some progress on binutils side, and I'll try to
>> update the GAS / ld patch set with relaxation included, by the end of this
>> month.
> 
> Thanks for the update.  I understand the complexity adding a runtime
> test when the feature also requires binutils and rtld support.
> I hope that we add a test checking assembly under
> gcc/testsuite/gcc.target/riscv/tls , otherwise as a non-default test,
> when this breaks, it may be difficult to figure it out.
> (glibc/elf/tst-* will need a runtime test, but GCC needs to have its own.)

Checking assembly sounds reasonable.  I’ll look into it after finishing the 
binutils stuff.

>> gcc/config.gcc  | 15 ++-
>> gcc/config/riscv/riscv-opts.h   |  6 ++
>> gcc/config/riscv/riscv-protos.h |  5 +++--
>> gcc/config/riscv/riscv.cc   | 24 
>> gcc/config/riscv/riscv.h|  9 +++--
>> gcc/config/riscv/riscv.md   | 21 -
>> gcc/config/riscv/riscv.opt  | 14 ++
>> gcc/doc/install.texi|  3 +++
>> gcc/doc/invoke.texi | 13 -
>> 9 files changed, 99 insertions(+), 11 deletions(-)
>> 
>> diff --git a/gcc/config.gcc b/gcc/config.gcc
>> index 415e0e1ebc5..2c1a7179b02 100644
>> --- a/gcc/config.gcc
>> +++ b/gcc/config.gcc
>> @@ -2434,6 +2434,7 @@ riscv*-*-linux*)
>># Force .init_array support.  The configure script cannot always
>># automatically detect that GAS supports it, yet we require it.
>>gcc_cv_initfini_array=yes
>> +   with_tls=${with_tls:-trad}
>>;;
>> riscv*-*-elf* | riscv*-*-rtems*)
>>tm_file="elfos.h newlib-stdint.h ${tm_file} riscv/elf.h"
>> @@ -2476,6 +2477,7 @@ riscv*-*-freebsd*)
>># Force .init_array support.  The configure script cannot always
>># automatically detect that GAS supports it, yet we require it.
>>gcc_cv_initfini_array=yes
>> +   with_tls=${with_tls:-trad}
>>;;
>> 
>> loongarch*-*-linux*)
>> @@ -4566,7 +4568,7 @@ case "${target}" in
>>;;
>> 
>>riscv*-*-*)
>> -   supported_defaults="abi arch tune riscv_attribute isa_sp

[PATCH v3] RISC-V: Implement TLS Descriptors.

[Tatsuyuki Ishi]

This implements TLS Descriptors (TLSDESC) as specified in [1].

The 4-instruction sequence is implemented as a single RTX insn for
simplicity, but this can be revisited later if instruction scheduling or
more flexible RA is desired.

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.
* doc/install.texi: Document --with-tls for RISC-V.
* doc/invoke.texi: Document --mtls-dialect for RISC-V.
---
No regression in gcc tests for rv64gc, tested alongside the binutils and
glibc implementation. Tested with --with_tls=desc.

v2: Add with_tls configuration option, and a few readability improvements.
Added Changelog.
v3: Add documentation per Kito's suggestion.
Fix minor issues pointed out by Kito and Jeff.
Thanks Kito Cheng and Jeff Law for review.

I've considered gating this behind a GAS feature test, but it seems
nontrivial especially for restricting the variants available at runtime.
Since TLS descriptors is not selected by default, I've decided to leave it
ungated.

In other news, I have made some progress on binutils side, and I'll try to
update the GAS / ld patch set with relaxation included, by the end of this
month.

 gcc/config.gcc  | 15 ++-
 gcc/config/riscv/riscv-opts.h   |  6 ++
 gcc/config/riscv/riscv-protos.h |  5 +++--
 gcc/config/riscv/riscv.cc   | 24 
 gcc/config/riscv/riscv.h|  9 +++--
 gcc/config/riscv/riscv.md   | 21 -
 gcc/config/riscv/riscv.opt  | 14 ++
 gcc/doc/install.texi|  3 +++
 gcc/doc/invoke.texi | 13 -
 9 files changed, 99 insertions(+), 11 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 415e0e1ebc5..2c1a7179b02 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2434,6 +2434,7 @@ riscv*-*-linux*)
# Force .init_array support.  The configure script cannot always
# automatically detect that GAS supports it, yet we require it.
gcc_cv_initfini_array=yes
+   with_tls=${with_tls:-trad}
;;
 riscv*-*-elf* | riscv*-*-rtems*)
tm_file="elfos.h newlib-stdint.h ${tm_file} riscv/elf.h"
@@ -2476,6 +2477,7 @@ riscv*-*-freebsd*)
# Force .init_array support.  The configure script cannot always
# automatically detect that GAS supports it, yet we require it.
gcc_cv_initfini_array=yes
+   with_tls=${with_tls:-trad}
;;
 
 loongarch*-*-linux*)
@@ -4566,7 +4568,7 @@ case "${target}" in
;;
 
riscv*-*-*)
-   supported_defaults="abi arch tune riscv_attribute isa_spec"
+   supported_defaults="abi arch tune riscv_attribute isa_spec tls"
 
case "${target}" in
riscv-* | riscv32*) xlen=32 ;;
@@ -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
 
# Handle --with-multilib-list.
if test "x${with_multilib_list}" != xdefault; then
diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index 378a17699cd..db03f35430a 100644
--- a/gcc/config/riscv/riscv-opts.h
+++ b/gcc/config/riscv/riscv-opts.h
@@ -319,4 +319,10 @@ enum riscv_entity
 #define TARGET_VECTOR_VLS  
\
   (TARGET_VECTOR && riscv_autovec_preference == RVV_SCALABLE)
 
+/* TLS types.  */
+enum riscv_tls_type {
+  TLS_TRADITIONAL,
+  TLS_DESCRIPTORS
+};
+
 #endif /* ! GCC_RISCV_OPTS_H */
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 472c00dc439..9b7471f7591 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -33,9 +33,10 @@

Re: [PATCH v2] RISC-V: Implement TLS Descriptors.

[Tatsuyuki Ishi]

> On Nov 16, 2023, at 14:33, Fangrui Song  wrote:
> 
> On Wed, Nov 15, 2023 at 9:23 PM Jeff Law  wrote:
>> 
>> 
>> 
>> On 11/15/23 18:51, Tatsuyuki Ishi wrote:
>>>> On Nov 16, 2023, at 10:07, Jeff Law  wrote:
>> 
>>> 
>>> Based on what I have read in the AArch64 backend, there are two ways to
>>> do this: introduce a custom calling convention, or put in a RTX insn
>>> that covers the whole sequence. Ideally we should do the first, but then
>>> there’s the label issue and it’s quite a bit more complicated. So I’m
>>> sticking with this for now.
>> As I said, I think we're OK here.  We can always revamp as we get
>> experience with the implementation -- I don't think any of the stuff
>> we're talking about is an ABI change, they're just implementation details.
>> 
>>> 
>>> Sorry for all the delay on this. My progress has been (and still)
>>> blocked on supporting relaxation of TLSDESC in binutils (turns out you
>>> can’t run static binaries without relaxing it first). But that doesn’t
>>> seem exactly easy to do either, because relaxation that involves GOT
>>> elimination isn’t something we have in the RISC-V backend.
>> Note that binutils is due for another release in the next month or two.
>> It'd certainly be helpful to have any issues there resolved in time for
>> that release.
>> 
>>> 
>>> I’ll try to send a new version of this patch and get this unblocked on
>>> GCC side first.
>> Sounds good.  We can always guard its use behind a feature test for GAS
>> support.
>> 
>> Jeff
> 
> Agreed.
> 
> 
> Tatsuyuki, could you also add some tests? For example
> 
> // end of https://maskray.me/blog/2021-02-14-all-about-thread-local-storage
> __thread int tls0;
> extern __thread int tls1;
> int foo() { return ++tls0 + ++tls1; }
> static __thread int tls2, tls3;
> int bar() { return ++tls2 + ++tls3; }
> 
> I have used this to check rtld and linker behavior. I think we need
> some `scan-assembler`.
> To make it a runnable test, some assembler feature check may be
> needed. Perhaps Jeff can make some suggestion or contribute code!
> 

I believe there’s existing platform-generic TLS coverage in 
gcc/testsuite/gcc.dg/torture/tls. GCC's test suite seems pretty sparse, but a 
lot more testing is done by glibc’s testsuite (which is also where I found the 
static TLS relaxation issue).

Tatsuyuki.

> 
> -- 
> 宋方睿

Re: [PATCH v2] RISC-V: Implement TLS Descriptors.

[Tatsuyuki Ishi]

> On Nov 16, 2023, at 10:07, Jeff Law  wrote:
> 
> 
> 
> 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?

Sorry, this was an oversight. I’ll fix it in the next version.

> 
>> @@ -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.

Based on what I have read in the AArch64 backend, there are two ways to do 
this: introduce a custom calling convention, or put in a RTX insn that covers 
the whole sequence. Ideally we should do the first, but then there’s the label 
issue and it’s quite a bit more complicated. So I’m sticking with this for now.

> 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.

Ack.

> So overall if Kito's OK, then I am with the trivial doc change and perhaps 
> the formatting fix in config.guess.

Sorry for all the delay on this. My progress has been (and still) blocked on 
supporting relaxation of TLSDESC in binutils (turns out you can’t run static 
binaries without relaxing it first). But that doesn’t seem exactly easy to do 
either, because relaxation that involves GOT elimination isn’t something we 
have in the RISC-V backend.

I’ll try to send a new version of this patch and get this unblocked on GCC side 
first.
Presumably this still needs the associated gas and ld support in place, so let 
me know if you want to merge this soon. I will ask on binutils for whether they 
could accept the basic part of the implementation without relaxation first.

Thanks,
Tatsuyuki. 

> jeff

Re: [PATCH v2] RISC-V: Implement TLS Descriptors.

[Tatsuyuki Ishi]

> On Nov 16, 2023, at 10:17, Fangrui Song  wrote:
> 
> On Mon, Oct 2, 2023 at 7:10 AM Kito Cheng  > wrote:
>> 
>> Just one nit and one more comment for doc:
>> 
>> Could you add some doc something like that? mostly I grab from other
>> target, so you can just included in the patch.
>> 
>> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
>> index 31f2234640f..39396668da2 100644
>> --- a/gcc/doc/install.texi
>> +++ b/gcc/doc/install.texi
>> @@ -1174,6 +1174,9 @@ Specify the default TLS dialect, for systems
>> were there is a choice.
>> For ARM targets, possible values for @var{dialect} are @code{gnu} or
>> @code{gnu2}, which select between the original GNU dialect and the GNU TLS
>> descriptor-based dialect.
>> +For RISC-V targets, possible values for @var{dialect} are @code{trad} or
>> +@code{desc}, which select between the traditional GNU dialect and the GNU 
>> TLS
>> +descriptor-based dialect.
>> 
>> @item --enable-multiarch
>> Specify whether to enable or disable multiarch support.  The default is
>> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
>> index 4085fc90907..459e266d426 100644
>> --- a/gcc/doc/invoke.texi
>> +++ b/gcc/doc/invoke.texi
>> @@ -1239,7 +1239,8 @@ See RS/6000 and PowerPC Options.
>> -minline-atomics  -mno-inline-atomics
>> -minline-strlen  -mno-inline-strlen
>> -minline-strcmp  -mno-inline-strcmp
>> --minline-strncmp  -mno-inline-strncmp}
>> +-minline-strncmp  -mno-inline-strncmp
>> +-mtls-dialect=desc  -mtls-dialect=trad}
>> 
>> @emph{RL78 Options}
>> @gccoptlist{-msim  -mmul=none  -mmul=g13  -mmul=g14  -mallregs
>> @@ -29538,6 +29539,17 @@ which register to use as base register for
>> reading the canary,
>> and from what offset from that base register. There is no default
>> register or offset as this is entirely for use within the Linux
>> kernel.
>> +
>> +@opindex mtls-dialect=desc
>> +@item -mtls-dialect=desc
>> +Use TLS descriptors as the thread-local storage mechanism for dynamic 
>> accesses
>> +of TLS variables.  This is the default.
>> +
>> +@opindex mtls-dialect=trad
>> +@item -mtls-dialect=traditional
> 
> -mtls-dialect=trad.
> aarch64-linux-gnu-gcc doesn't support -mtls-dialect=traditional
> 
>> +Use traditional TLS as the thread-local storage mechanism for dynamic 
>> accesses
>> +of TLS variables.
>> +
>> @end table
> 
> This is the default :)
> 
> I am happy that we change the default like AArch64, but probably not
> now when linker support is not widely available yet.
> 
> I cannot comment on the code side as I am not familiar with GCC internals.
> 
>> @node RL78 Options
>> 
>> 
>> 
>> 
>>> +(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))]
>> 
>> P rather than SI here.
>> 
>>> +  "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" "")])
>>> +
>>> (define_insn "auipc"
>>>   [(set (match_operand:P   0 "register_operand" "=r")
>>>(unspec:P
> 
> It seems that x86-64 supports non-adjacent code sequence. Writing the
> pattern this way does not allow interleaving, but I assume
> interleaving doesn't enable much.
> https://reviews.llvm.org/D114416

As mentioned in the commit message, the use of relaxation-only labels does not 
seem well supported in current GCC. Creating a label seems to force a basic 
block and I’m not sure how we can avoid it.

If there’s a better way to implement this I’m happy to adopt.

Tatsuyuki.

> 
> -- 
> 宋方睿

Re: [PATCH] Do not prepend target triple to -fuse-ld=lld,mold.

[Tatsuyuki Ishi]

> On Nov 7, 2023, at 23:37, Richard Biener  wrote:
> 
> On Tue, 7 Nov 2023, Tatsuyuki Ishi wrote:
> 
>>> On Oct 16, 2023, at 18:16, Richard Biener  wrote:
>>> 
>>> On Mon, 16 Oct 2023, Tatsuyuki Ishi wrote:
>>> 
>>>> 
>>>> 
>>>>> On Oct 16, 2023, at 17:55, Richard Biener  wrote:
>>>>> 
>>>>> On Mon, 16 Oct 2023, Tatsuyuki Ishi wrote:
>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Oct 16, 2023, at 17:39, Richard Biener  wrote:
>>>>>>> 
>>>>>>> On Mon, 16 Oct 2023, Tatsuyuki Ishi wrote:
>>>>>>> 
>>>>>>>> lld and mold are platform-agnostic and not prefixed with target triple.
>>>>>>>> Prepending the target triple makes it less likely to find the intended
>>>>>>>> linker executable.
>>>>>>>> 
>>>>>>>> A potential breaking change is that we no longer try to search for
>>>>>>>> triple-prefixed lld/mold binaries anymore. However, since there doesn't
>>>>>>>> seem to be support to build LLVM or mold with triple-prefixed 
>>>>>>>> executable
>>>>>>>> names, it seems better to just not bother with that case.
>>>>>>>> 
>>>>>>>>PR driver/111605
>>>>>>>> 
>>>>>>>> gcc/Changelog:
>>>>>>>> 
>>>>>>>>* collect2.cc (main): Do not prepend target triple to
>>>>>>>>-fuse-ld=lld,mold.
>>>>>>>> ---
>>>>>>>> gcc/collect2.cc | 13 -
>>>>>>>> 1 file changed, 8 insertions(+), 5 deletions(-)
>>>>>>>> 
>>>>>>>> diff --git a/gcc/collect2.cc b/gcc/collect2.cc
>>>>>>>> index 63b9a0c233a..c943f9f577c 100644
>>>>>>>> --- a/gcc/collect2.cc
>>>>>>>> +++ b/gcc/collect2.cc
>>>>>>>> @@ -865,12 +865,15 @@ main (int argc, char **argv)
>>>>>>>> int i;
>>>>>>>> 
>>>>>>>> for (i = 0; i < USE_LD_MAX; i++)
>>>>>>>> -full_ld_suffixes[i]
>>>>>>>> #ifdef CROSS_DIRECTORY_STRUCTURE
>>>>>>>> -  = concat (target_machine, "-", ld_suffixes[i], NULL);
>>>>>>>> -#else
>>>>>>>> -  = ld_suffixes[i];
>>>>>>>> -#endif
>>>>>>>> +/* lld and mold are platform-agnostic and not prefixed with target
>>>>>>>> +   triple.  */
>>>>>>>> +if (!(i == USE_LLD_LD || i == USE_MOLD_LD))
>>>>>>>> +  full_ld_suffixes[i] = concat (target_machine, "-", 
>>>>>>>> ld_suffixes[i],
>>>>>>>> +  NULL);
>>>>>>>> +else
>>>>>>>> +#endif
>>>>>>>> +  full_ld_suffixes[i] = ld_suffixes[i];
>>>>>>>> 
>>>>>>>> p = argv[0] + strlen (argv[0]);
>>>>>>>> while (p != argv[0] && !IS_DIR_SEPARATOR (p[-1]))
>>>>>>> 
>>>>>>> Since we later do
>>>>>>> 
>>>>>>> /* Search the compiler directories for `ld'.  We have protection against
>>>>>>>  recursive calls in find_a_file.  */
>>>>>>> if (ld_file_name == 0)
>>>>>>> ld_file_name = find_a_file (&cpath, ld_suffixes[selected_linker], 
>>>>>>> X_OK);
>>>>>>> /* Search the ordinary system bin directories
>>>>>>>  for `ld' (if native linking) or `TARGET-ld' (if cross).  */
>>>>>>> if (ld_file_name == 0)
>>>>>>> ld_file_name = find_a_file (&path, full_ld_suffixes[selected_linker], 
>>>>>>> X_OK);
>>>>>>> 
>>>>>>> I wonder how having full_ld_suffixes[LLD|MOLD] == ld_suffixes[LLD|MOLD]
>>>>>>> fixes anything?
>>>>>> 
>>>>>> Per the linked PR, the intended use case for this is when one wants to 
>>>>>> use their system lld/mold with a separately packaged cross toolchain, 
>>>>>> without

Re: [PATCH] Do not prepend target triple to -fuse-ld=lld,mold.

[Tatsuyuki Ishi]

> On Oct 16, 2023, at 18:16, Richard Biener  wrote:
> 
> On Mon, 16 Oct 2023, Tatsuyuki Ishi wrote:
> 
>> 
>> 
>>> On Oct 16, 2023, at 17:55, Richard Biener  wrote:
>>> 
>>> On Mon, 16 Oct 2023, Tatsuyuki Ishi wrote:
>>> 
>>>> 
>>>> 
>>>>> On Oct 16, 2023, at 17:39, Richard Biener  wrote:
>>>>> 
>>>>> On Mon, 16 Oct 2023, Tatsuyuki Ishi wrote:
>>>>> 
>>>>>> lld and mold are platform-agnostic and not prefixed with target triple.
>>>>>> Prepending the target triple makes it less likely to find the intended
>>>>>> linker executable.
>>>>>> 
>>>>>> A potential breaking change is that we no longer try to search for
>>>>>> triple-prefixed lld/mold binaries anymore. However, since there doesn't
>>>>>> seem to be support to build LLVM or mold with triple-prefixed executable
>>>>>> names, it seems better to just not bother with that case.
>>>>>> 
>>>>>>  PR driver/111605
>>>>>> 
>>>>>> gcc/Changelog:
>>>>>> 
>>>>>>  * collect2.cc (main): Do not prepend target triple to
>>>>>>  -fuse-ld=lld,mold.
>>>>>> ---
>>>>>> gcc/collect2.cc | 13 -
>>>>>> 1 file changed, 8 insertions(+), 5 deletions(-)
>>>>>> 
>>>>>> diff --git a/gcc/collect2.cc b/gcc/collect2.cc
>>>>>> index 63b9a0c233a..c943f9f577c 100644
>>>>>> --- a/gcc/collect2.cc
>>>>>> +++ b/gcc/collect2.cc
>>>>>> @@ -865,12 +865,15 @@ main (int argc, char **argv)
>>>>>> int i;
>>>>>> 
>>>>>> for (i = 0; i < USE_LD_MAX; i++)
>>>>>> -full_ld_suffixes[i]
>>>>>> #ifdef CROSS_DIRECTORY_STRUCTURE
>>>>>> -  = concat (target_machine, "-", ld_suffixes[i], NULL);
>>>>>> -#else
>>>>>> -  = ld_suffixes[i];
>>>>>> -#endif
>>>>>> +/* lld and mold are platform-agnostic and not prefixed with target
>>>>>> +   triple.  */
>>>>>> +if (!(i == USE_LLD_LD || i == USE_MOLD_LD))
>>>>>> +  full_ld_suffixes[i] = concat (target_machine, "-", ld_suffixes[i],
>>>>>> +NULL);
>>>>>> +else
>>>>>> +#endif
>>>>>> +  full_ld_suffixes[i] = ld_suffixes[i];
>>>>>> 
>>>>>> p = argv[0] + strlen (argv[0]);
>>>>>> while (p != argv[0] && !IS_DIR_SEPARATOR (p[-1]))
>>>>> 
>>>>> Since we later do
>>>>> 
>>>>> /* Search the compiler directories for `ld'.  We have protection against
>>>>>   recursive calls in find_a_file.  */
>>>>> if (ld_file_name == 0)
>>>>>  ld_file_name = find_a_file (&cpath, ld_suffixes[selected_linker], 
>>>>> X_OK);
>>>>> /* Search the ordinary system bin directories
>>>>>   for `ld' (if native linking) or `TARGET-ld' (if cross).  */
>>>>> if (ld_file_name == 0)
>>>>>  ld_file_name = find_a_file (&path, full_ld_suffixes[selected_linker], 
>>>>> X_OK);
>>>>> 
>>>>> I wonder how having full_ld_suffixes[LLD|MOLD] == ld_suffixes[LLD|MOLD]
>>>>> fixes anything?
>>>> 
>>>> Per the linked PR, the intended use case for this is when one wants to use 
>>>> their system lld/mold with a separately packaged cross toolchain, without 
>>>> requiring them to symlink their system lld/mold into the cross toolchain 
>>>> bin directory.
>>>> 
>>>> (Note that the first search is against COMPILER_PATH while the latter is 
>>>> against PATH).
>>> 
>>> Ah.  So what about instead adding here
>>> 
>>>  /* Search the ordinary system bin directories for mold/lld even in
>>> a cross configuration.  */
>>>  if (ld_file_name == 0
>>>  && selected_linker == ...)
>>>ld_file_name = find_a_file (&path, ld_suffixes[selected_linker], X_OK);
>>> 
>>> instead?  That would keep things working in case the user has a
>>> xyz-arch-mold in the system dir but uses GNU ld on the host
>>> otherwise, lacking a 

Re: [PATCH] Do not prepend target triple to -fuse-ld=lld,mold.

[Tatsuyuki Ishi]

> On Oct 16, 2023, at 17:55, Richard Biener  wrote:
> 
> On Mon, 16 Oct 2023, Tatsuyuki Ishi wrote:
> 
>> 
>> 
>>> On Oct 16, 2023, at 17:39, Richard Biener  wrote:
>>> 
>>> On Mon, 16 Oct 2023, Tatsuyuki Ishi wrote:
>>> 
>>>> lld and mold are platform-agnostic and not prefixed with target triple.
>>>> Prepending the target triple makes it less likely to find the intended
>>>> linker executable.
>>>> 
>>>> A potential breaking change is that we no longer try to search for
>>>> triple-prefixed lld/mold binaries anymore. However, since there doesn't
>>>> seem to be support to build LLVM or mold with triple-prefixed executable
>>>> names, it seems better to just not bother with that case.
>>>> 
>>>>PR driver/111605
>>>> 
>>>> gcc/Changelog:
>>>> 
>>>>* collect2.cc (main): Do not prepend target triple to
>>>>-fuse-ld=lld,mold.
>>>> ---
>>>> gcc/collect2.cc | 13 -
>>>> 1 file changed, 8 insertions(+), 5 deletions(-)
>>>> 
>>>> diff --git a/gcc/collect2.cc b/gcc/collect2.cc
>>>> index 63b9a0c233a..c943f9f577c 100644
>>>> --- a/gcc/collect2.cc
>>>> +++ b/gcc/collect2.cc
>>>> @@ -865,12 +865,15 @@ main (int argc, char **argv)
>>>>  int i;
>>>> 
>>>>  for (i = 0; i < USE_LD_MAX; i++)
>>>> -full_ld_suffixes[i]
>>>> #ifdef CROSS_DIRECTORY_STRUCTURE
>>>> -  = concat (target_machine, "-", ld_suffixes[i], NULL);
>>>> -#else
>>>> -  = ld_suffixes[i];
>>>> -#endif
>>>> +/* lld and mold are platform-agnostic and not prefixed with target
>>>> +   triple.  */
>>>> +if (!(i == USE_LLD_LD || i == USE_MOLD_LD))
>>>> +  full_ld_suffixes[i] = concat (target_machine, "-", ld_suffixes[i],
>>>> +  NULL);
>>>> +else
>>>> +#endif
>>>> +  full_ld_suffixes[i] = ld_suffixes[i];
>>>> 
>>>>  p = argv[0] + strlen (argv[0]);
>>>>  while (p != argv[0] && !IS_DIR_SEPARATOR (p[-1]))
>>> 
>>> Since we later do
>>> 
>>> /* Search the compiler directories for `ld'.  We have protection against
>>>recursive calls in find_a_file.  */
>>> if (ld_file_name == 0)
>>>   ld_file_name = find_a_file (&cpath, ld_suffixes[selected_linker], 
>>> X_OK);
>>> /* Search the ordinary system bin directories
>>>for `ld' (if native linking) or `TARGET-ld' (if cross).  */
>>> if (ld_file_name == 0)
>>>   ld_file_name = find_a_file (&path, full_ld_suffixes[selected_linker], 
>>> X_OK);
>>> 
>>> I wonder how having full_ld_suffixes[LLD|MOLD] == ld_suffixes[LLD|MOLD]
>>> fixes anything?
>> 
>> Per the linked PR, the intended use case for this is when one wants to use 
>> their system lld/mold with a separately packaged cross toolchain, without 
>> requiring them to symlink their system lld/mold into the cross toolchain bin 
>> directory.
>> 
>> (Note that the first search is against COMPILER_PATH while the latter is 
>> against PATH).
> 
> Ah.  So what about instead adding here
> 
>   /* Search the ordinary system bin directories for mold/lld even in
>  a cross configuration.  */
>   if (ld_file_name == 0
>   && selected_linker == ...)
> ld_file_name = find_a_file (&path, ld_suffixes[selected_linker], X_OK);
> 
> instead?  That would keep things working in case the user has a
> xyz-arch-mold in the system dir but uses GNU ld on the host
> otherwise, lacking a 'mold' binary there?
> 
> That is, we'd only add, not change what we search for.

I considered that, but as described in commit message, it doesn’t seem anyone 
has created stuff named xyz-arch-lld or xyz-arch-mold. Closest is Gentoo’s 
symlink mentioned in this thread, but that’s xyz-arch-ld -> ld.lld/mold.
As such, this feels like a quirk, not something we need to keep compatibility 
for.

The proposed change seems simple enough though, so if you consider this a 
compatibility issue I can go for that way as well.

Tatsuyuki.

> 
> Thanks,
> Richard.

Re: [PATCH] Do not prepend target triple to -fuse-ld=lld,mold.

[Tatsuyuki Ishi]

> On Oct 16, 2023, at 17:39, Richard Biener  wrote:
> 
> On Mon, 16 Oct 2023, Tatsuyuki Ishi wrote:
> 
>> lld and mold are platform-agnostic and not prefixed with target triple.
>> Prepending the target triple makes it less likely to find the intended
>> linker executable.
>> 
>> A potential breaking change is that we no longer try to search for
>> triple-prefixed lld/mold binaries anymore. However, since there doesn't
>> seem to be support to build LLVM or mold with triple-prefixed executable
>> names, it seems better to just not bother with that case.
>> 
>>  PR driver/111605
>> 
>> gcc/Changelog:
>> 
>>  * collect2.cc (main): Do not prepend target triple to
>>  -fuse-ld=lld,mold.
>> ---
>> gcc/collect2.cc | 13 -
>> 1 file changed, 8 insertions(+), 5 deletions(-)
>> 
>> diff --git a/gcc/collect2.cc b/gcc/collect2.cc
>> index 63b9a0c233a..c943f9f577c 100644
>> --- a/gcc/collect2.cc
>> +++ b/gcc/collect2.cc
>> @@ -865,12 +865,15 @@ main (int argc, char **argv)
>>   int i;
>> 
>>   for (i = 0; i < USE_LD_MAX; i++)
>> -full_ld_suffixes[i]
>> #ifdef CROSS_DIRECTORY_STRUCTURE
>> -  = concat (target_machine, "-", ld_suffixes[i], NULL);
>> -#else
>> -  = ld_suffixes[i];
>> -#endif
>> +/* lld and mold are platform-agnostic and not prefixed with target
>> +   triple.  */
>> +if (!(i == USE_LLD_LD || i == USE_MOLD_LD))
>> +  full_ld_suffixes[i] = concat (target_machine, "-", ld_suffixes[i],
>> +NULL);
>> +else
>> +#endif
>> +  full_ld_suffixes[i] = ld_suffixes[i];
>> 
>>   p = argv[0] + strlen (argv[0]);
>>   while (p != argv[0] && !IS_DIR_SEPARATOR (p[-1]))
> 
> Since we later do
> 
>  /* Search the compiler directories for `ld'.  We have protection against
> recursive calls in find_a_file.  */
>  if (ld_file_name == 0)
>ld_file_name = find_a_file (&cpath, ld_suffixes[selected_linker], 
> X_OK);
>  /* Search the ordinary system bin directories
> for `ld' (if native linking) or `TARGET-ld' (if cross).  */
>  if (ld_file_name == 0)
>ld_file_name = find_a_file (&path, full_ld_suffixes[selected_linker], 
> X_OK);
> 
> I wonder how having full_ld_suffixes[LLD|MOLD] == ld_suffixes[LLD|MOLD]
> fixes anything?

Per the linked PR, the intended use case for this is when one wants to use 
their system lld/mold with a separately packaged cross toolchain, without 
requiring them to symlink their system lld/mold into the cross toolchain bin 
directory.

(Note that the first search is against COMPILER_PATH while the latter is 
against PATH).

Tatsuyuki.

> 
> Richard.

[PATCH] Do not prepend target triple to -fuse-ld=lld,mold.

[Tatsuyuki Ishi]

lld and mold are platform-agnostic and not prefixed with target triple.
Prepending the target triple makes it less likely to find the intended
linker executable.

A potential breaking change is that we no longer try to search for
triple-prefixed lld/mold binaries anymore. However, since there doesn't
seem to be support to build LLVM or mold with triple-prefixed executable
names, it seems better to just not bother with that case.

PR driver/111605

gcc/Changelog:

* collect2.cc (main): Do not prepend target triple to
-fuse-ld=lld,mold.
---
 gcc/collect2.cc | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/gcc/collect2.cc b/gcc/collect2.cc
index 63b9a0c233a..c943f9f577c 100644
--- a/gcc/collect2.cc
+++ b/gcc/collect2.cc
@@ -865,12 +865,15 @@ main (int argc, char **argv)
   int i;
 
   for (i = 0; i < USE_LD_MAX; i++)
-full_ld_suffixes[i]
 #ifdef CROSS_DIRECTORY_STRUCTURE
-  = concat (target_machine, "-", ld_suffixes[i], NULL);
-#else
-  = ld_suffixes[i];
-#endif
+/* lld and mold are platform-agnostic and not prefixed with target
+   triple.  */
+if (!(i == USE_LLD_LD || i == USE_MOLD_LD))
+  full_ld_suffixes[i] = concat (target_machine, "-", ld_suffixes[i],
+   NULL);
+else
+#endif
+  full_ld_suffixes[i] = ld_suffixes[i];
 
   p = argv[0] + strlen (argv[0]);
   while (p != argv[0] && !IS_DIR_SEPARATOR (p[-1]))
-- 
2.42.0

[PATCH v2] RISC-V: Implement TLS Descriptors.

[Tatsuyuki Ishi via Gcc-patches]

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.
---
No regression in gcc tests for rv64gc, tested alongside the binutils and
glibc implementation. Tested with --with_tls=desc.

v2: Add with_tls configuration option, and a few readability improvements.
Added Changelog.
Thanks Kito Cheng for the review.

This contribution is made on behalf of Blue Whale Systems, which has
copyright assignment on file with the FSF.

 gcc/config.gcc  | 15 ++-
 gcc/config/riscv/riscv-opts.h   |  6 ++
 gcc/config/riscv/riscv-protos.h |  5 +++--
 gcc/config/riscv/riscv.cc   | 24 
 gcc/config/riscv/riscv.h|  9 +++--
 gcc/config/riscv/riscv.md   | 21 -
 gcc/config/riscv/riscv.opt  | 14 ++
 7 files changed, 84 insertions(+), 10 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 415e0e1ebc5..86df7b89016 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2434,6 +2434,7 @@ riscv*-*-linux*)
# Force .init_array support.  The configure script cannot always
# automatically detect that GAS supports it, yet we require it.
gcc_cv_initfini_array=yes
+   with_tls=${with_tls:-trad}
;;
 riscv*-*-elf* | riscv*-*-rtems*)
tm_file="elfos.h newlib-stdint.h ${tm_file} riscv/elf.h"
@@ -2476,6 +2477,7 @@ riscv*-*-freebsd*)
# Force .init_array support.  The configure script cannot always
# automatically detect that GAS supports it, yet we require it.
gcc_cv_initfini_array=yes
+   with_tls=${with_tls:-trad}
;;
 
 loongarch*-*-linux*)
@@ -4566,7 +4568,7 @@ case "${target}" in
;;
 
riscv*-*-*)
-   supported_defaults="abi arch tune riscv_attribute isa_spec"
+   supported_defaults="abi arch tune riscv_attribute isa_spec tls"
 
case "${target}" in
riscv-* | riscv32*) xlen=32 ;;
@@ -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
 
# Handle --with-multilib-list.
if test "x${with_multilib_list}" != xdefault; then
diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index 378a17699cd..db03f35430a 100644
--- a/gcc/config/riscv/riscv-opts.h
+++ b/gcc/config/riscv/riscv-opts.h
@@ -319,4 +319,10 @@ enum riscv_entity
 #define TARGET_VECTOR_VLS  
\
   (TARGET_VECTOR && riscv_autovec_preference == RVV_SCALABLE)
 
+/* TLS types.  */
+enum riscv_tls_type {
+  TLS_TRADITIONAL,
+  TLS_DESCRIPTORS
+};
+
 #endif /* ! GCC_RISCV_OPTS_H */
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 472c00dc439..9b7471f7591 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -33,9 +33,10 @@ enum riscv_symbol_type {
   SYMBOL_TLS,
   SYMBOL_TLS_LE,
   SYMBOL_TLS_IE,
-  SYMBOL_TLS_GD
+  SYMBOL_TLS_GD,
+  SYMBOL_TLSDESC,
 };
-#define NUM_SYMBOL_TYPES (SYMBOL_TLS_GD + 1)
+#define NUM_SYMBOL_TYPES (SYMBOL_TLSDESC + 1)
 
 /* Classifies an address.
 
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 49062bef9fc..c158e224aaa 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -799,6 +799,7 @@ static int riscv_symbol_insns (enum riscv_symbol_type type)
 case SYMBOL_ABSOLUTE: return 2; /* LUI + the reference.  */
 case SYMBOL

[PATCH] RISC-V: Implement TLS Descriptors.

[Tatsuyuki Ishi via Gcc-patches]

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.

For now, keep defaulting to the traditional TLS model, but this can be
revisited once toolchain and libc support ships.

[1]: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373
---
No regression in binutils and gcc tests for rv64gc, tested alongside the
binutils and glibc implementation (posted at the same time). During
testing, the default TLS dialect was changed to TLSDESC.

This contribution is made on behalf of Blue Whale Systems, which has
copyright assignment on file with the FSF.

 gcc/config/riscv/riscv-opts.h   |  6 ++
 gcc/config/riscv/riscv-protos.h |  5 +++--
 gcc/config/riscv/riscv.cc   | 34 +
 gcc/config/riscv/riscv.h|  3 +++
 gcc/config/riscv/riscv.md   | 22 -
 gcc/config/riscv/riscv.opt  | 14 ++
 6 files changed, 77 insertions(+), 7 deletions(-)

diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index 378a17699cd..db03f35430a 100644
--- a/gcc/config/riscv/riscv-opts.h
+++ b/gcc/config/riscv/riscv-opts.h
@@ -319,4 +319,10 @@ enum riscv_entity
 #define TARGET_VECTOR_VLS  
\
   (TARGET_VECTOR && riscv_autovec_preference == RVV_SCALABLE)
 
+/* TLS types.  */
+enum riscv_tls_type {
+  TLS_TRADITIONAL,
+  TLS_DESCRIPTORS
+};
+
 #endif /* ! GCC_RISCV_OPTS_H */
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 472c00dc439..9b7471f7591 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -33,9 +33,10 @@ enum riscv_symbol_type {
   SYMBOL_TLS,
   SYMBOL_TLS_LE,
   SYMBOL_TLS_IE,
-  SYMBOL_TLS_GD
+  SYMBOL_TLS_GD,
+  SYMBOL_TLSDESC,
 };
-#define NUM_SYMBOL_TYPES (SYMBOL_TLS_GD + 1)
+#define NUM_SYMBOL_TYPES (SYMBOL_TLSDESC + 1)
 
 /* Classifies an address.
 
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 49062bef9fc..4ff0adbbb1e 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -799,6 +799,7 @@ static int riscv_symbol_insns (enum riscv_symbol_type type)
 case SYMBOL_ABSOLUTE: return 2; /* LUI + the reference.  */
 case SYMBOL_PCREL: return 2; /* AUIPC + the reference.  */
 case SYMBOL_TLS_LE: return 3; /* LUI + ADD TP + the reference.  */
+case SYMBOL_TLSDESC: return 6; /* 4-instruction call + ADD TP + the 
reference.  */
 case SYMBOL_GOT_DISP: return 3; /* AUIPC + LD GOT + the reference.  */
 default: gcc_unreachable ();
 }
@@ -1601,6 +1602,16 @@ static rtx riscv_tls_add_tp_le (rtx dest, rtx base, rtx 
sym)
 return gen_tls_add_tp_lesi (dest, base, tp, sym);
 }
 
+/* Instruction sequence to call the TLS Descriptor resolver.  */
+
+static rtx riscv_tlsdesc (rtx sym, rtx seqno)
+{
+  if (Pmode == DImode)
+return gen_tlsdescdi (sym, seqno);
+  else
+return gen_tlsdescsi (sym, seqno);
+}
+
 /* If MODE is MAX_MACHINE_MODE, ADDR appears as a move operand, otherwise
it appears in a MEM of that mode.  Return true if ADDR is a legitimate
constant in that context and can be split into high and low parts.
@@ -1734,7 +1745,7 @@ riscv_call_tls_get_addr (rtx sym, rtx result)
 static rtx
 riscv_legitimize_tls_address (rtx loc)
 {
-  rtx dest, tp, tmp;
+  rtx dest, tp, tmp, a0;
   enum tls_model model = SYMBOL_REF_TLS_MODEL (loc);
 
 #if 0
@@ -1750,9 +1761,24 @@ riscv_legitimize_tls_address (rtx loc)
   /* Rely on section anchors for the optimization that LDM TLS
 provides.  The anchor's address is loaded with GD TLS. */
 case TLS_MODEL_GLOBAL_DYNAMIC:
-  tmp = gen_rtx_REG (Pmode, GP_RETURN);
-  dest = gen_reg_rtx (Pmode);
-  emit_libcall_block (riscv_call_tls_get_addr (loc, tmp), dest, tmp, loc);
+  if (TARGET_TLSDESC)
+   {
+ static unsigned seqno;
+ tp = gen_rtx_REG (Pmode, THREAD_POINTER_REGNUM);
+ a0 = gen_rtx_REG (Pmode, GP_ARG_FIRST);
+ dest = gen_reg_rtx (Pmode);
+
+ emit_insn (riscv_tlsdesc (loc, GEN_INT (seqno)));
+ emit_insn (gen_add3_insn (dest, a0, tp));
+ seqno++;
+   }
+  else
+   {
+ tmp = gen_rtx_REG (Pmode, GP_RETURN);
+ dest = gen_reg_rtx (Pmode);
+ emit_libcall_block (riscv_call_tls_get_addr (loc, tmp), dest, tmp,
+ loc);
+   }
   break;
 
 case TLS_MODEL_INITIAL_EXEC:
diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
index e18a0081297..7cf1365ec08 100644
--- a/gcc/config/riscv/riscv.h
+++ b/gcc/config/riscv/riscv.h
@@ -1122,4 +1122,7 @@ extern void riscv_remove_unneeded_save_restore_calls 
(void);
 #define OPTIMIZE_MOD