Re: [PATCH] RISC-V: Update multilib-generator to handle V
Write a primary version for that, did you mind giving it a try?
The basic idea is to select multilib only by ABI, so that we don't
need to bother with endless multilib reuse cases...
On Wed, Apr 19, 2023 at 9:38 AM Kito Cheng wrote:
>
> OK, thanks, I know what the problem is, I tried rv64 but didn't try
> rv32, I have another fix in my mind, and will post another fix soon.
>
> On Wed, Apr 19, 2023 at 9:29 AM Palmer Dabbelt wrote:
> >
> > On Tue, 18 Apr 2023 18:26:18 PDT (-0700), Kito Cheng wrote:
> > > And which -march -mabi you used will got issue?
> > >
> > > On Wed, Apr 19, 2023 at 8:51 AM Palmer Dabbelt
> > > wrote:
> > >>
> > >> On Tue, 18 Apr 2023 17:47:31 PDT (-0700), Kito Cheng wrote:
> > >> > Do you mind shared gcc configure and the option you tried?
> > >>
> > >> Just riscv-gnu-toolchain with "--enbale-multilib --enable-linux".
> > >>
> > >> > On Wed, Apr 19, 2023 at 4:01 AM Palmer Dabbelt
> > >> > wrote:
> > >> >>
> > >> >> On Tue, 18 Apr 2023 08:44:24 PDT (-0700), gcc-patches@gcc.gnu.org
> > >> >> wrote:
> > >> >> >> Yep, if I drop the non-canonicial strings via
> > >> >> >>
> > >> >> >> diff --git a/gcc/config/riscv/multilib-generator
> > >> >> >> b/gcc/config/riscv/multilib-generator
> > >> >> >> index 58b7198b243..a63a4d69c18 100755
> > >> >> >> --- a/gcc/config/riscv/multilib-generator
> > >> >> >> +++ b/gcc/config/riscv/multilib-generator
> > >> >> >> @@ -174,7 +174,7 @@ for cmodel in cmodels:
> > >> >> >> ext_combs = expand_combination(ext)
> > >> >> >> alts = sum([[x] + [x + y for y in ext_combs] for x in
> > >> >> >> [arch] + extra], [])
> > >> >> >> alts = filter(lambda x: len(x) != 0, alts)
> > >> >> >> -alts = alts + list(map(lambda a : arch_canonicalize(a,
> > >> >> >> args.misa_spec), alts))
> > >> >> >> +alts = list(map(lambda a : arch_canonicalize(a,
> > >> >> >> args.misa_spec), alts))
> > >> >> >>
> > >> >> >> # Drop duplicated entry.
> > >> >> >> alts = unique(alts)
> > >> >> >>
> > >> >> >> then I can't link `-march=rv32imafdcv`, I need
> > >> >> >> `-march=rv32imacv_zicsr_zve32f_zve32x_zve64x_zvl128b_zvl32b_zvl64b`.
> > >> >> >> That's
> > >> >> >> kind of a headache for users to type in.
> > >> >> >
> > >> >> > Yes, that's a headache for users, but arch string canonicalization
> > >> >> > is
> > >> >> > hiddened at the process,
> > >> >> > so the user could still just use rv32imafdcv at compile time and
> > >> >> > multi-lib config.
> > >> >> >
> > >> >> > And the driver and multilib-generator (with arch_canonicalize)
> > >> >> > script
> > >> >> > will handle those headache in the background.
> > >> >>
> > >> >> Sorry, I'm not exactly sure what you're trying to say. I just rebuilt
> > >> >> GCC with this patch (and t-linux-multilib regenerated from it), it's
> > >> >> not
> > >> >> resolving multlibs for the short names.
> >
> > `-march=rv32imafdcv` is the broken one,
> > `-march=rv32imacv_zicsr_zve32f_zve32x_zve64x_zvl128b_zvl32b_zvl64b`
> > resolves multilibs (there's a bit more above).
From a92c0cb2ce6fa58939331549bfb9e8110ec86a11 Mon Sep 17 00:00:00 2001
From: Kito Cheng
Date: Wed, 19 Apr 2023 11:54:42 +0800
Subject: [PATCH] RISC-V: Handle multi-lib path correclty for linux [DRAFT]
---
gcc/common/config/riscv/riscv-common.cc | 118
gcc/config/riscv/linux.h| 13 ++-
2 files changed, 90 insertions(+), 41 deletions(-)
diff --git a/gcc/common/config/riscv/riscv-common.cc b/gcc/common/config/riscv/riscv-common.cc
index 2fc0f8bffc1..f40b1b617c2 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -1597,6 +1597,73 @@ riscv_check_conds (
return match_score + ok_count * 100;
}
+static const char *
+riscv_select_multilib_by_abi (
+ const std::string _current_arch_str,
+ const std::string _current_abi_str,
+ const riscv_subset_list *subset_list,
+ const struct switchstr *switches,
+ int n_switches,
+ const std::vector _infos
+ )
+{
+ for (size_t i = 0; i < multilib_infos.size (); ++i)
+if (riscv_current_abi_str == multilib_infos[i].abi_str)
+ return xstrdup (multilib_infos[i].path.c_str ());
+
+ return NULL;
+}
+
+
+static const char *
+riscv_select_multilib (
+ const std::string _current_arch_str,
+ const std::string _current_abi_str,
+ const riscv_subset_list *subset_list,
+ const struct switchstr *switches,
+ int n_switches,
+ const std::vector _infos
+ )
+{
+ int match_score = 0;
+ int max_match_score = 0;
+ int best_match_multi_lib = -1;
+ /* Try to decision which set we should used. */
+ /* We have 3 level decision tree here, ABI, check input arch/ABI must
+ be superset of multi-lib arch, and other rest option checking. */
+ for (size_t i = 0; i < multilib_infos.size (); ++i)
+{
+ /* Check ABI is same first. */
+ if (riscv_current_abi_str != multilib_infos[i].abi_str)
+ continue;
+
+ /* Found a potential compatible
Re: [PATCH] RISC-V: Update multilib-generator to handle V
OK, thanks, I know what the problem is, I tried rv64 but didn't try rv32, I have another fix in my mind, and will post another fix soon. On Wed, Apr 19, 2023 at 9:29 AM Palmer Dabbelt wrote: > > On Tue, 18 Apr 2023 18:26:18 PDT (-0700), Kito Cheng wrote: > > And which -march -mabi you used will got issue? > > > > On Wed, Apr 19, 2023 at 8:51 AM Palmer Dabbelt wrote: > >> > >> On Tue, 18 Apr 2023 17:47:31 PDT (-0700), Kito Cheng wrote: > >> > Do you mind shared gcc configure and the option you tried? > >> > >> Just riscv-gnu-toolchain with "--enbale-multilib --enable-linux". > >> > >> > On Wed, Apr 19, 2023 at 4:01 AM Palmer Dabbelt > >> > wrote: > >> >> > >> >> On Tue, 18 Apr 2023 08:44:24 PDT (-0700), gcc-patches@gcc.gnu.org wrote: > >> >> >> Yep, if I drop the non-canonicial strings via > >> >> >> > >> >> >> diff --git a/gcc/config/riscv/multilib-generator > >> >> >> b/gcc/config/riscv/multilib-generator > >> >> >> index 58b7198b243..a63a4d69c18 100755 > >> >> >> --- a/gcc/config/riscv/multilib-generator > >> >> >> +++ b/gcc/config/riscv/multilib-generator > >> >> >> @@ -174,7 +174,7 @@ for cmodel in cmodels: > >> >> >> ext_combs = expand_combination(ext) > >> >> >> alts = sum([[x] + [x + y for y in ext_combs] for x in > >> >> >> [arch] + extra], []) > >> >> >> alts = filter(lambda x: len(x) != 0, alts) > >> >> >> -alts = alts + list(map(lambda a : arch_canonicalize(a, > >> >> >> args.misa_spec), alts)) > >> >> >> +alts = list(map(lambda a : arch_canonicalize(a, > >> >> >> args.misa_spec), alts)) > >> >> >> > >> >> >> # Drop duplicated entry. > >> >> >> alts = unique(alts) > >> >> >> > >> >> >> then I can't link `-march=rv32imafdcv`, I need > >> >> >> `-march=rv32imacv_zicsr_zve32f_zve32x_zve64x_zvl128b_zvl32b_zvl64b`. > >> >> >> That's > >> >> >> kind of a headache for users to type in. > >> >> > > >> >> > Yes, that's a headache for users, but arch string canonicalization is > >> >> > hiddened at the process, > >> >> > so the user could still just use rv32imafdcv at compile time and > >> >> > multi-lib config. > >> >> > > >> >> > And the driver and multilib-generator (with arch_canonicalize) script > >> >> > will handle those headache in the background. > >> >> > >> >> Sorry, I'm not exactly sure what you're trying to say. I just rebuilt > >> >> GCC with this patch (and t-linux-multilib regenerated from it), it's not > >> >> resolving multlibs for the short names. > > `-march=rv32imafdcv` is the broken one, > `-march=rv32imacv_zicsr_zve32f_zve32x_zve64x_zvl128b_zvl32b_zvl64b` > resolves multilibs (there's a bit more above).
Re: [PATCH] RISC-V: Update multilib-generator to handle V
On Tue, 18 Apr 2023 18:26:18 PDT (-0700), Kito Cheng wrote: And which -march -mabi you used will got issue? On Wed, Apr 19, 2023 at 8:51 AM Palmer Dabbelt wrote: On Tue, 18 Apr 2023 17:47:31 PDT (-0700), Kito Cheng wrote: > Do you mind shared gcc configure and the option you tried? Just riscv-gnu-toolchain with "--enbale-multilib --enable-linux". > On Wed, Apr 19, 2023 at 4:01 AM Palmer Dabbelt wrote: >> >> On Tue, 18 Apr 2023 08:44:24 PDT (-0700), gcc-patches@gcc.gnu.org wrote: >> >> Yep, if I drop the non-canonicial strings via >> >> >> >> diff --git a/gcc/config/riscv/multilib-generator b/gcc/config/riscv/multilib-generator >> >> index 58b7198b243..a63a4d69c18 100755 >> >> --- a/gcc/config/riscv/multilib-generator >> >> +++ b/gcc/config/riscv/multilib-generator >> >> @@ -174,7 +174,7 @@ for cmodel in cmodels: >> >> ext_combs = expand_combination(ext) >> >> alts = sum([[x] + [x + y for y in ext_combs] for x in [arch] + extra], []) >> >> alts = filter(lambda x: len(x) != 0, alts) >> >> -alts = alts + list(map(lambda a : arch_canonicalize(a, args.misa_spec), alts)) >> >> +alts = list(map(lambda a : arch_canonicalize(a, args.misa_spec), alts)) >> >> >> >> # Drop duplicated entry. >> >> alts = unique(alts) >> >> >> >> then I can't link `-march=rv32imafdcv`, I need >> >> `-march=rv32imacv_zicsr_zve32f_zve32x_zve64x_zvl128b_zvl32b_zvl64b`. That's >> >> kind of a headache for users to type in. >> > >> > Yes, that's a headache for users, but arch string canonicalization is >> > hiddened at the process, >> > so the user could still just use rv32imafdcv at compile time and >> > multi-lib config. >> > >> > And the driver and multilib-generator (with arch_canonicalize) script >> > will handle those headache in the background. >> >> Sorry, I'm not exactly sure what you're trying to say. I just rebuilt >> GCC with this patch (and t-linux-multilib regenerated from it), it's not >> resolving multlibs for the short names. `-march=rv32imafdcv` is the broken one, `-march=rv32imacv_zicsr_zve32f_zve32x_zve64x_zvl128b_zvl32b_zvl64b` resolves multilibs (there's a bit more above).
Re: [PATCH] RISC-V: Update multilib-generator to handle V
And which -march -mabi you used will got issue? On Wed, Apr 19, 2023 at 8:51 AM Palmer Dabbelt wrote: > > On Tue, 18 Apr 2023 17:47:31 PDT (-0700), Kito Cheng wrote: > > Do you mind shared gcc configure and the option you tried? > > Just riscv-gnu-toolchain with "--enbale-multilib --enable-linux". > > > On Wed, Apr 19, 2023 at 4:01 AM Palmer Dabbelt wrote: > >> > >> On Tue, 18 Apr 2023 08:44:24 PDT (-0700), gcc-patches@gcc.gnu.org wrote: > >> >> Yep, if I drop the non-canonicial strings via > >> >> > >> >> diff --git a/gcc/config/riscv/multilib-generator > >> >> b/gcc/config/riscv/multilib-generator > >> >> index 58b7198b243..a63a4d69c18 100755 > >> >> --- a/gcc/config/riscv/multilib-generator > >> >> +++ b/gcc/config/riscv/multilib-generator > >> >> @@ -174,7 +174,7 @@ for cmodel in cmodels: > >> >> ext_combs = expand_combination(ext) > >> >> alts = sum([[x] + [x + y for y in ext_combs] for x in [arch] + > >> >> extra], []) > >> >> alts = filter(lambda x: len(x) != 0, alts) > >> >> -alts = alts + list(map(lambda a : arch_canonicalize(a, > >> >> args.misa_spec), alts)) > >> >> +alts = list(map(lambda a : arch_canonicalize(a, > >> >> args.misa_spec), alts)) > >> >> > >> >> # Drop duplicated entry. > >> >> alts = unique(alts) > >> >> > >> >> then I can't link `-march=rv32imafdcv`, I need > >> >> `-march=rv32imacv_zicsr_zve32f_zve32x_zve64x_zvl128b_zvl32b_zvl64b`. > >> >> That's > >> >> kind of a headache for users to type in. > >> > > >> > Yes, that's a headache for users, but arch string canonicalization is > >> > hiddened at the process, > >> > so the user could still just use rv32imafdcv at compile time and > >> > multi-lib config. > >> > > >> > And the driver and multilib-generator (with arch_canonicalize) script > >> > will handle those headache in the background. > >> > >> Sorry, I'm not exactly sure what you're trying to say. I just rebuilt > >> GCC with this patch (and t-linux-multilib regenerated from it), it's not > >> resolving multlibs for the short names.
Re: [PATCH] RISC-V: Update multilib-generator to handle V
On Tue, 18 Apr 2023 17:47:31 PDT (-0700), Kito Cheng wrote: Do you mind shared gcc configure and the option you tried? Just riscv-gnu-toolchain with "--enbale-multilib --enable-linux". On Wed, Apr 19, 2023 at 4:01 AM Palmer Dabbelt wrote: On Tue, 18 Apr 2023 08:44:24 PDT (-0700), gcc-patches@gcc.gnu.org wrote: >> Yep, if I drop the non-canonicial strings via >> >> diff --git a/gcc/config/riscv/multilib-generator b/gcc/config/riscv/multilib-generator >> index 58b7198b243..a63a4d69c18 100755 >> --- a/gcc/config/riscv/multilib-generator >> +++ b/gcc/config/riscv/multilib-generator >> @@ -174,7 +174,7 @@ for cmodel in cmodels: >> ext_combs = expand_combination(ext) >> alts = sum([[x] + [x + y for y in ext_combs] for x in [arch] + extra], []) >> alts = filter(lambda x: len(x) != 0, alts) >> -alts = alts + list(map(lambda a : arch_canonicalize(a, args.misa_spec), alts)) >> +alts = list(map(lambda a : arch_canonicalize(a, args.misa_spec), alts)) >> >> # Drop duplicated entry. >> alts = unique(alts) >> >> then I can't link `-march=rv32imafdcv`, I need >> `-march=rv32imacv_zicsr_zve32f_zve32x_zve64x_zvl128b_zvl32b_zvl64b`. That's >> kind of a headache for users to type in. > > Yes, that's a headache for users, but arch string canonicalization is > hiddened at the process, > so the user could still just use rv32imafdcv at compile time and > multi-lib config. > > And the driver and multilib-generator (with arch_canonicalize) script > will handle those headache in the background. Sorry, I'm not exactly sure what you're trying to say. I just rebuilt GCC with this patch (and t-linux-multilib regenerated from it), it's not resolving multlibs for the short names.
Re: [PATCH] RISC-V: Update multilib-generator to handle V
Do you mind shared gcc configure and the option you tried? On Wed, Apr 19, 2023 at 4:01 AM Palmer Dabbelt wrote: > > On Tue, 18 Apr 2023 08:44:24 PDT (-0700), gcc-patches@gcc.gnu.org wrote: > >> Yep, if I drop the non-canonicial strings via > >> > >> diff --git a/gcc/config/riscv/multilib-generator > >> b/gcc/config/riscv/multilib-generator > >> index 58b7198b243..a63a4d69c18 100755 > >> --- a/gcc/config/riscv/multilib-generator > >> +++ b/gcc/config/riscv/multilib-generator > >> @@ -174,7 +174,7 @@ for cmodel in cmodels: > >> ext_combs = expand_combination(ext) > >> alts = sum([[x] + [x + y for y in ext_combs] for x in [arch] + > >> extra], []) > >> alts = filter(lambda x: len(x) != 0, alts) > >> -alts = alts + list(map(lambda a : arch_canonicalize(a, > >> args.misa_spec), alts)) > >> +alts = list(map(lambda a : arch_canonicalize(a, args.misa_spec), > >> alts)) > >> > >> # Drop duplicated entry. > >> alts = unique(alts) > >> > >> then I can't link `-march=rv32imafdcv`, I need > >> `-march=rv32imacv_zicsr_zve32f_zve32x_zve64x_zvl128b_zvl32b_zvl64b`. > >> That's > >> kind of a headache for users to type in. > > > > Yes, that's a headache for users, but arch string canonicalization is > > hiddened at the process, > > so the user could still just use rv32imafdcv at compile time and > > multi-lib config. > > > > And the driver and multilib-generator (with arch_canonicalize) script > > will handle those headache in the background. > > Sorry, I'm not exactly sure what you're trying to say. I just rebuilt > GCC with this patch (and t-linux-multilib regenerated from it), it's not > resolving multlibs for the short names.
Re: [PATCH] RISC-V: Update multilib-generator to handle V
On Tue, 18 Apr 2023 08:44:24 PDT (-0700), gcc-patches@gcc.gnu.org wrote: Yep, if I drop the non-canonicial strings via diff --git a/gcc/config/riscv/multilib-generator b/gcc/config/riscv/multilib-generator index 58b7198b243..a63a4d69c18 100755 --- a/gcc/config/riscv/multilib-generator +++ b/gcc/config/riscv/multilib-generator @@ -174,7 +174,7 @@ for cmodel in cmodels: ext_combs = expand_combination(ext) alts = sum([[x] + [x + y for y in ext_combs] for x in [arch] + extra], []) alts = filter(lambda x: len(x) != 0, alts) -alts = alts + list(map(lambda a : arch_canonicalize(a, args.misa_spec), alts)) +alts = list(map(lambda a : arch_canonicalize(a, args.misa_spec), alts)) # Drop duplicated entry. alts = unique(alts) then I can't link `-march=rv32imafdcv`, I need `-march=rv32imacv_zicsr_zve32f_zve32x_zve64x_zvl128b_zvl32b_zvl64b`. That's kind of a headache for users to type in. Yes, that's a headache for users, but arch string canonicalization is hiddened at the process, so the user could still just use rv32imafdcv at compile time and multi-lib config. And the driver and multilib-generator (with arch_canonicalize) script will handle those headache in the background. Sorry, I'm not exactly sure what you're trying to say. I just rebuilt GCC with this patch (and t-linux-multilib regenerated from it), it's not resolving multlibs for the short names.
Re: [PATCH] RISC-V: Update multilib-generator to handle V
> Yep, if I drop the non-canonicial strings via > > diff --git a/gcc/config/riscv/multilib-generator > b/gcc/config/riscv/multilib-generator > index 58b7198b243..a63a4d69c18 100755 > --- a/gcc/config/riscv/multilib-generator > +++ b/gcc/config/riscv/multilib-generator > @@ -174,7 +174,7 @@ for cmodel in cmodels: > ext_combs = expand_combination(ext) > alts = sum([[x] + [x + y for y in ext_combs] for x in [arch] + > extra], []) > alts = filter(lambda x: len(x) != 0, alts) > -alts = alts + list(map(lambda a : arch_canonicalize(a, > args.misa_spec), alts)) > +alts = list(map(lambda a : arch_canonicalize(a, args.misa_spec), > alts)) > > # Drop duplicated entry. > alts = unique(alts) > > then I can't link `-march=rv32imafdcv`, I need > `-march=rv32imacv_zicsr_zve32f_zve32x_zve64x_zvl128b_zvl32b_zvl64b`. That's > kind of a headache for users to type in. Yes, that's a headache for users, but arch string canonicalization is hiddened at the process, so the user could still just use rv32imafdcv at compile time and multi-lib config. And the driver and multilib-generator (with arch_canonicalize) script will handle those headache in the background.
Re: [PATCH] RISC-V: Update multilib-generator to handle V
On Mon, 17 Apr 2023 08:24:44 PDT (-0700), Palmer Dabbelt wrote:
> On Fri, 14 Apr 2023 00:15:07 PDT (-0700), Kito Cheng wrote:
>> Wait, take second round review:
>>
>>> * All extensions were being prefixed with an underscore, which leads to
>>> some odd combinations like "rv32gc_v", this just adds underscores to
>>> the multi-letter extensions.
>>> * The input base ISAs were being canonicalized, which resulted in some
>>> odd multilib default search paths. I'm not sure if anything breaks
>>> due to this, but it seems safer to just leave them alone.
>>
>>>* All extensions were being prefixed with an underscore, which leads to
>>> some odd combinations like "rv32gc_v", this just adds underscores to
>>> the multi-letter extensions.
>>
>> I think that weirdness can be removed arch-canonicalize I think?
>>
>> And currently all -march will be canonicalized before query multi lib
>>
>>> @@ -163,14 +168,13 @@ for cmodel in cmodels:
>>> if cmodel == "compact" and arch.startswith("rv32"):
>>>continue
>>>
>>> -arch = arch_canonicalize (arch, args.misa_spec)
>>> arches[arch] = 1
>>> abis[abi] = 1
>>> extra = list(filter(None, extra.split(',')))
>>> ext_combs = expand_combination(ext)
>>> alts = sum([[x] + [x + y for y in ext_combs] for x in [arch] + extra],
>>> [])
>>> alts = filter(lambda x: len(x) != 0, alts)
>>> -alts = list(map(lambda a : arch_canonicalize(a, args.misa_spec), alts))
>>> +alts = alts + list(map(lambda a : arch_canonicalize(a,
>>> args.misa_spec), alts))
>>
>> So we don't really need to append non-canonical one to the list?
>
> IIUC the multilib processing happens before the canonicialization, so
> we'd need the non-canonicial strings in there too (as those are what
> most users will provide, and what we have now). I haven't actually
> tested that, though...
Yep, if I drop the non-canonicial strings via
diff --git a/gcc/config/riscv/multilib-generator
b/gcc/config/riscv/multilib-generator
index 58b7198b243..a63a4d69c18 100755
--- a/gcc/config/riscv/multilib-generator
+++ b/gcc/config/riscv/multilib-generator
@@ -174,7 +174,7 @@ for cmodel in cmodels:
ext_combs = expand_combination(ext)
alts = sum([[x] + [x + y for y in ext_combs] for x in [arch] + extra],
[])
alts = filter(lambda x: len(x) != 0, alts)
-alts = alts + list(map(lambda a : arch_canonicalize(a,
args.misa_spec), alts))
+alts = list(map(lambda a : arch_canonicalize(a, args.misa_spec), alts))
# Drop duplicated entry.
alts = unique(alts)
then I can't link `-march=rv32imafdcv`, I need
`-march=rv32imacv_zicsr_zve32f_zve32x_zve64x_zvl128b_zvl32b_zvl64b`. That's
kind of a headache for users to type in.
Re: [PATCH] RISC-V: Update multilib-generator to handle V
On Fri, 14 Apr 2023 00:15:07 PDT (-0700), Kito Cheng wrote:
Wait, take second round review:
* All extensions were being prefixed with an underscore, which leads to
some odd combinations like "rv32gc_v", this just adds underscores to
the multi-letter extensions.
* The input base ISAs were being canonicalized, which resulted in some
odd multilib default search paths. I'm not sure if anything breaks
due to this, but it seems safer to just leave them alone.
* All extensions were being prefixed with an underscore, which leads to
some odd combinations like "rv32gc_v", this just adds underscores to
the multi-letter extensions.
I think that weirdness can be removed arch-canonicalize I think?
And currently all -march will be canonicalized before query multi lib
@@ -163,14 +168,13 @@ for cmodel in cmodels:
if cmodel == "compact" and arch.startswith("rv32"):
continue
-arch = arch_canonicalize (arch, args.misa_spec)
arches[arch] = 1
abis[abi] = 1
extra = list(filter(None, extra.split(',')))
ext_combs = expand_combination(ext)
alts = sum([[x] + [x + y for y in ext_combs] for x in [arch] + extra], [])
alts = filter(lambda x: len(x) != 0, alts)
-alts = list(map(lambda a : arch_canonicalize(a, args.misa_spec), alts))
+alts = alts + list(map(lambda a : arch_canonicalize(a, args.misa_spec),
alts))
So we don't really need to append non-canonical one to the list?
IIUC the multilib processing happens before the canonicialization, so
we'd need the non-canonicial strings in there too (as those are what
most users will provide, and what we have now). I haven't actually
tested that, though...
Re: [PATCH] RISC-V: Update multilib-generator to handle V
Wait, take second round review:
> * All extensions were being prefixed with an underscore, which leads to
> some odd combinations like "rv32gc_v", this just adds underscores to
> the multi-letter extensions.
> * The input base ISAs were being canonicalized, which resulted in some
> odd multilib default search paths. I'm not sure if anything breaks
> due to this, but it seems safer to just leave them alone.
>* All extensions were being prefixed with an underscore, which leads to
> some odd combinations like "rv32gc_v", this just adds underscores to
> the multi-letter extensions.
I think that weirdness can be removed arch-canonicalize I think?
And currently all -march will be canonicalized before query multi lib
> @@ -163,14 +168,13 @@ for cmodel in cmodels:
> if cmodel == "compact" and arch.startswith("rv32"):
>continue
>
> -arch = arch_canonicalize (arch, args.misa_spec)
> arches[arch] = 1
> abis[abi] = 1
> extra = list(filter(None, extra.split(',')))
> ext_combs = expand_combination(ext)
> alts = sum([[x] + [x + y for y in ext_combs] for x in [arch] + extra],
> [])
> alts = filter(lambda x: len(x) != 0, alts)
> -alts = list(map(lambda a : arch_canonicalize(a, args.misa_spec), alts))
> +alts = alts + list(map(lambda a : arch_canonicalize(a, args.misa_spec),
> alts))
So we don't really need to append non-canonical one to the list?
Re: [PATCH] RISC-V: Update multilib-generator to handle V
Thanks for catch this, I didn't enable multilib for linux toolchain
for a while,
I guess we should implement TARGET_COMPUTE_MULTILIB for linux targets
to simplify the damm multilib files, but I agree it's too late in the
release cycle, so let's fix that in this way for now.
So LGTM and OK for trunk, thanks
On Fri, Apr 14, 2023 at 4:55 AM Palmer Dabbelt wrote:
>
> It looks like multilib-generator hasn't been run for t-linux-multilib in
> a while and it's pretty broken. In order to regenerate the stub with
> support for V I needed a pair of fixes:
>
> * All extensions were being prefixed with an underscore, which leads to
> some odd combinations like "rv32gc_v", this just adds underscores to
> the multi-letter extensions.
> * The input base ISAs were being canonicalized, which resulted in some
> odd multilib default search paths. I'm not sure if anything breaks
> due to this, but it seems safer to just leave them alone.
>
> We've likely got a bunch more issues here related to multlib path
> mangling in the presence of underscores and for other extensions, but
> this at leasts lets me run the testsuite with V enabled.
>
> gcc/ChangeLog:
>
> * config/riscv/multilib-generator (maybe_add_underscore): New
> function
> (_expand_combination): Canonicalize differently.
> * config/riscv/t-linux-multilib: Regenerate.
> ---
> We're probably going to need a bunch more work here to handle the
> ISA-dependent multilib resolution, but I don't think that's gcc-13
> material -- certainly I don't have the time to do it, and even if it was
> ready now I'd bet it's too invasive for this point in the development
> cycle.
>
> We probably also want to handle the various B extensions in here, since
> those are upstream and useful. I'm going to hold off on that for a bit
> as I've got some V-related testsuite failures that I'd rather look at
> first. I figured it'd be better to just send this now, though, as at
> least I can run the V test suite under multilib.
>
> OK for trunk?
>
> ---
> gcc/config/riscv/multilib-generator | 18 +++---
> gcc/config/riscv/t-linux-multilib | 86 ++---
> 2 files changed, 78 insertions(+), 26 deletions(-)
>
> diff --git a/gcc/config/riscv/multilib-generator
> b/gcc/config/riscv/multilib-generator
> index 0a3d4c07757..58b7198b243 100755
> --- a/gcc/config/riscv/multilib-generator
> +++ b/gcc/config/riscv/multilib-generator
> @@ -62,6 +62,15 @@ def arch_canonicalize(arch, isa_spec):
>out, err = proc.communicate()
>return out.decode().strip()
>
> +#
> +# Multi-letter extensions are seperated by underscores, but single-letter
> +# extensions are not.
> +#
> +def maybe_add_underscore(ext):
> + if len(ext) is 1:
> +return ext
> + return '_' + ext
> +
> #
> # Handle expansion operation.
> #
> @@ -70,11 +79,7 @@ def arch_canonicalize(arch, isa_spec):
> #
> def _expand_combination(ext):
>exts = list(ext.split("*"))
> -
> - # Add underline to every extension.
> - # e.g.
> - # _b * zvamo => _b * _zvamo
> - exts = list(map(lambda x: '_' + x, exts))
> + exts = list(map(lambda x: maybe_add_underscore(x), exts))
>
># No need to expand if there is no `*`.
>if len(exts) == 1:
> @@ -163,14 +168,13 @@ for cmodel in cmodels:
> if cmodel == "compact" and arch.startswith("rv32"):
>continue
>
> -arch = arch_canonicalize (arch, args.misa_spec)
> arches[arch] = 1
> abis[abi] = 1
> extra = list(filter(None, extra.split(',')))
> ext_combs = expand_combination(ext)
> alts = sum([[x] + [x + y for y in ext_combs] for x in [arch] + extra],
> [])
> alts = filter(lambda x: len(x) != 0, alts)
> -alts = list(map(lambda a : arch_canonicalize(a, args.misa_spec), alts))
> +alts = alts + list(map(lambda a : arch_canonicalize(a, args.misa_spec),
> alts))
>
> # Drop duplicated entry.
> alts = unique(alts)
> diff --git a/gcc/config/riscv/t-linux-multilib
> b/gcc/config/riscv/t-linux-multilib
> index 298547fee38..400cf7f0634 100644
> --- a/gcc/config/riscv/t-linux-multilib
> +++ b/gcc/config/riscv/t-linux-multilib
> @@ -1,46 +1,94 @@
> # This file was generated by multilib-generator with the command:
> -# ./multilib-generator
> rv32imac-ilp32-rv32ima,rv32imaf,rv32imafd,rv32imafc,rv32imafdc-
> rv32imafdc-ilp32d-rv32imafd-
> rv64imac-lp64-rv64ima,rv64imaf,rv64imafd,rv64imafc,rv64imafdc-
> rv64imafdc-lp64d-rv64imafd-
> -MULTILIB_OPTIONS =
> march=rv32imac/march=rv32ima/march=rv32imaf/march=rv32imafd/march=rv32imafc/march=rv32imafdc/march=rv32g/march=rv32gc/march=rv64imac/march=rv64ima/march=rv64imaf/march=rv64imafd/march=rv64imafc/march=rv64imafdc/march=rv64g/march=rv64gc
> mabi=ilp32/mabi=ilp32d/mabi=lp64/mabi=lp64d
> +# ./multilib-generator
> rv32imac-ilp32-rv32ima,rv32imaf,rv32imafd,rv32imafc,rv32imafdc-v
> rv32imafdc-ilp32d-rv32imafd-v
> rv64imac-lp64-rv64ima,rv64imaf,rv64imafd,rv64imafc,rv64imafdc-v
> rv64imafdc-lp64d-rv64imafd-v
>
[PATCH] RISC-V: Update multilib-generator to handle V
It looks like multilib-generator hasn't been run for t-linux-multilib in
a while and it's pretty broken. In order to regenerate the stub with
support for V I needed a pair of fixes:
* All extensions were being prefixed with an underscore, which leads to
some odd combinations like "rv32gc_v", this just adds underscores to
the multi-letter extensions.
* The input base ISAs were being canonicalized, which resulted in some
odd multilib default search paths. I'm not sure if anything breaks
due to this, but it seems safer to just leave them alone.
We've likely got a bunch more issues here related to multlib path
mangling in the presence of underscores and for other extensions, but
this at leasts lets me run the testsuite with V enabled.
gcc/ChangeLog:
* config/riscv/multilib-generator (maybe_add_underscore): New
function
(_expand_combination): Canonicalize differently.
* config/riscv/t-linux-multilib: Regenerate.
---
We're probably going to need a bunch more work here to handle the
ISA-dependent multilib resolution, but I don't think that's gcc-13
material -- certainly I don't have the time to do it, and even if it was
ready now I'd bet it's too invasive for this point in the development
cycle.
We probably also want to handle the various B extensions in here, since
those are upstream and useful. I'm going to hold off on that for a bit
as I've got some V-related testsuite failures that I'd rather look at
first. I figured it'd be better to just send this now, though, as at
least I can run the V test suite under multilib.
OK for trunk?
---
gcc/config/riscv/multilib-generator | 18 +++---
gcc/config/riscv/t-linux-multilib | 86 ++---
2 files changed, 78 insertions(+), 26 deletions(-)
diff --git a/gcc/config/riscv/multilib-generator
b/gcc/config/riscv/multilib-generator
index 0a3d4c07757..58b7198b243 100755
--- a/gcc/config/riscv/multilib-generator
+++ b/gcc/config/riscv/multilib-generator
@@ -62,6 +62,15 @@ def arch_canonicalize(arch, isa_spec):
out, err = proc.communicate()
return out.decode().strip()
+#
+# Multi-letter extensions are seperated by underscores, but single-letter
+# extensions are not.
+#
+def maybe_add_underscore(ext):
+ if len(ext) is 1:
+return ext
+ return '_' + ext
+
#
# Handle expansion operation.
#
@@ -70,11 +79,7 @@ def arch_canonicalize(arch, isa_spec):
#
def _expand_combination(ext):
exts = list(ext.split("*"))
-
- # Add underline to every extension.
- # e.g.
- # _b * zvamo => _b * _zvamo
- exts = list(map(lambda x: '_' + x, exts))
+ exts = list(map(lambda x: maybe_add_underscore(x), exts))
# No need to expand if there is no `*`.
if len(exts) == 1:
@@ -163,14 +168,13 @@ for cmodel in cmodels:
if cmodel == "compact" and arch.startswith("rv32"):
continue
-arch = arch_canonicalize (arch, args.misa_spec)
arches[arch] = 1
abis[abi] = 1
extra = list(filter(None, extra.split(',')))
ext_combs = expand_combination(ext)
alts = sum([[x] + [x + y for y in ext_combs] for x in [arch] + extra], [])
alts = filter(lambda x: len(x) != 0, alts)
-alts = list(map(lambda a : arch_canonicalize(a, args.misa_spec), alts))
+alts = alts + list(map(lambda a : arch_canonicalize(a, args.misa_spec),
alts))
# Drop duplicated entry.
alts = unique(alts)
diff --git a/gcc/config/riscv/t-linux-multilib
b/gcc/config/riscv/t-linux-multilib
index 298547fee38..400cf7f0634 100644
--- a/gcc/config/riscv/t-linux-multilib
+++ b/gcc/config/riscv/t-linux-multilib
@@ -1,46 +1,94 @@
# This file was generated by multilib-generator with the command:
-# ./multilib-generator
rv32imac-ilp32-rv32ima,rv32imaf,rv32imafd,rv32imafc,rv32imafdc-
rv32imafdc-ilp32d-rv32imafd-
rv64imac-lp64-rv64ima,rv64imaf,rv64imafd,rv64imafc,rv64imafdc-
rv64imafdc-lp64d-rv64imafd-
-MULTILIB_OPTIONS =
march=rv32imac/march=rv32ima/march=rv32imaf/march=rv32imafd/march=rv32imafc/march=rv32imafdc/march=rv32g/march=rv32gc/march=rv64imac/march=rv64ima/march=rv64imaf/march=rv64imafd/march=rv64imafc/march=rv64imafdc/march=rv64g/march=rv64gc
mabi=ilp32/mabi=ilp32d/mabi=lp64/mabi=lp64d
+# ./multilib-generator
rv32imac-ilp32-rv32ima,rv32imaf,rv32imafd,rv32imafc,rv32imafdc-v
rv32imafdc-ilp32d-rv32imafd-v
rv64imac-lp64-rv64ima,rv64imaf,rv64imafd,rv64imafc,rv64imafdc-v
rv64imafdc-lp64d-rv64imafd-v
+MULTILIB_OPTIONS =
