[PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.

[PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.

[Jin Ma]

When testing a extension, it is often necessary for a certain program not to
need some kind of extension, such as the bitmanip extension, to evaluate the
performance or codesize of the extension. However, the current multilib rules
will report an error when it is not a superset of the MULTILIB_REQUIRED list,
which will cause the program to be unable to link normally, thus failing to
achieve the expected purpose.

Therefore, the compilation option is added to avoid riscv_multi_lib_check()
interruption of compilation.

gcc/ChangeLog:

	* config/riscv/elf.h (LIB_SPEC): Do not run riscv_multi_lib_check() when
	-mdisable-multilib-check.
	* config/riscv/riscv.opt: New.
---
 gcc/config/riscv/elf.h     | 2 +-
 gcc/config/riscv/riscv.opt | 4 ++++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/config/riscv/elf.h b/gcc/config/riscv/elf.h
index 4b7e5c988ca..afde1b12d36 100644
--- a/gcc/config/riscv/elf.h
+++ b/gcc/config/riscv/elf.h
@@ -29,7 +29,7 @@ along with GCC; see the file COPYING3.  If not see
 #undef  LIB_SPEC
 #define LIB_SPEC \
   "--start-group -lc %{!specs=nosys.specs:-lgloss} --end-group " \
-  "%{!nostartfiles:%{!nodefaultlibs:%{!nolibc:%{!nostdlib:%:riscv_multi_lib_check()}}}}"
+  "%{!mdisable-multilib-check:%{!nostartfiles:%{!nodefaultlibs:%{!nolibc:%{!nostdlib:%:riscv_multi_lib_check()}}}}}"
 
 #undef  STARTFILE_SPEC
 #define STARTFILE_SPEC "crt0%O%s crtbegin%O%s"
diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
index 63d4710cb15..9940a24a7f9 100644
--- a/gcc/config/riscv/riscv.opt
+++ b/gcc/config/riscv/riscv.opt
@@ -295,3 +295,7 @@ Enum(riscv_autovec_lmul) String(m8) Value(RVV_M8)
 -param=riscv-autovec-lmul=
 Target RejectNegative Joined Enum(riscv_autovec_lmul) Var(riscv_autovec_lmul) Init(RVV_M1)
 -param=riscv-autovec-lmul=<string>	Set the RVV LMUL of auto-vectorization in the RISC-V port.
+
+mdisable-multilib-check
+Target Bool Var(riscv_disable_multilib_check) Init(0)
+Disable multilib checking by riscv_multi_lib_check().
-- 
2.17.1

Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.

[Kito Cheng]

> When testing a extension, it is often necessary for a certain program not to
> need some kind of extension, such as the bitmanip extension, to evaluate the
> performance or codesize of the extension. However, the current multilib rules
> will report an error when it is not a superset of the MULTILIB_REQUIRED list,
> which will cause the program to be unable to link normally, thus failing to
> achieve the expected purpose.
>
> Therefore, the compilation option is added to avoid riscv_multi_lib_check()
> interruption of compilation.

I think it's dangerous to remove the check, but I can understand there
are some cases where we really do not want the `security lock`,
so I am OK with introducing a new option to disable that.
but plz add documentation to the option into gcc/doc/invoke.texi
and mention it will just use default multilib and MIGHT not be correct
in some cases.

> --- a/gcc/config/riscv/riscv.opt
> +++ b/gcc/config/riscv/riscv.opt
> @@ -295,3 +295,7 @@ Enum(riscv_autovec_lmul) String(m8) Value(RVV_M8)
>  -param=riscv-autovec-lmul=
>  Target RejectNegative Joined Enum(riscv_autovec_lmul) Var(riscv_autovec_lmul) Init(RVV_M1)
>  -param=riscv-autovec-lmul=<string>     Set the RVV LMUL of auto-vectorization in the RISC-V port.
> +
> +mdisable-multilib-check

I would like to rename that to mno-multilib-check since that is more
like all other gcc option conventions.

> +Target Bool Var(riscv_disable_multilib_check) Init(0)

You don't need Var(riscv_disable_multilib_check) and Init(0) since no
one check the value
And you need RejectNegative to prevent gcc accept -mno-disable-multilib-check

> +Disable multilib checking by riscv_multi_lib_check().

`riscv_multi_lib_check()` is meanless for users since it's
implementation detail.
`Disable multilib checking; use the default multilib if a compatible
one is not found.`

Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.

[Maciej W. Rozycki]

On Tue, 23 May 2023, Jin Ma via Gcc-patches wrote:

> When testing a extension, it is often necessary for a certain program not to
> need some kind of extension, such as the bitmanip extension, to evaluate the
> performance or codesize of the extension. However, the current multilib rules
> will report an error when it is not a superset of the MULTILIB_REQUIRED list,
> which will cause the program to be unable to link normally, thus failing to
> achieve the expected purpose.

 Hmm, I have troubles understanding what is going on here.  What do you 
refer to by saying: "it is not a superset of the MULTILIB_REQUIRED list"?  

 There should be no problem with linking compiled modules together that 
make use of different extensions, with the static linker figuring out the 
combined set of extensions actually required at run time for the program 
loader to consider, as long as the modules do not have contradicting 
requirements, e.g. big vs little endianness or RV32 vs RV64.

 Can you give me a specific example (compilation options and multilibs 
available) of a failure you refer to?

 Is this something that could be solved without resorting to a possibly 
dangerous hack, by making use of MULTILIB_REUSE?

  Maciej

Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.

[Jin Ma]

> > When testing a extension, it is often necessary for a certain program not to
> > need some kind of extension, such as the bitmanip extension, to evaluate the
> > performance or codesize of the extension. However, the current multilib rules
> > will report an error when it is not a superset of the MULTILIB_REQUIRED list,
> > which will cause the program to be unable to link normally, thus failing to
> > achieve the expected purpose.
> 
>  Hmm, I have troubles understanding what is going on here.  What do you 
> refer to by saying: "it is not a superset of the MULTILIB_REQUIRED list"?

This is a new matching rule added by kito for the multilib of riscv:
https://github.com/gcc-mirror/gcc/commit/d72ca12b846a9f5c01674b280b1817876c77888f

>  There should be no problem with linking compiled modules together that 
> make use of different extensions, with the static linker figuring out the 
> combined set of extensions actually required at run time for the program 
> loader to consider, as long as the modules do not have contradicting 
> requirements, e.g. big vs little endianness or RV32 vs RV64.
> 
>  Can you give me a specific example (compilation options and multilibs 
> available) of a failure you refer to?

A simple example:
1. Use "--disable-multilib --with-abi =lp64d --with-arch =rv64imafdc_zba_zbb_zbc_zbs"
to build the toolchain".
2. Use the toolchain to test the impact of zba_zbb_zbc_zbs extensions on the
performance and codesize of some functions or files in the program.

In this case, I may need to use the command "-mabi=lp64d -march=rv64imafdc" for
the compilation of a specific .c file in the program, which will cause the link to
fail and throw the following error: "FATAL ERROR: Can't find suitable multilib set for
'-march=rv64imafdc'/'-mabi=lp64d'". This does not satisfy the purpose of the test.

I think this needs an option to turn off this check. Users sometimes, just as
gcc uses the default multilib when it does not match the appropriate multilib,
do not need the `security lock`, and should already understand the risks
of using this option.

>  Is this something that could be solved without resorting to a possibly 
> dangerous hack, by making use of MULTILIB_REUSE?

Regarding the use of MULTILIB_REUSE, I think kito's patch has already been explained
and is currently implemented according to the new rules.
https://github.com/gcc-mirror/gcc/commit/5ca9980fc86242505ffdaaf62bca1fd5db26550b

> 
>   Maciej

Thanks,
Jin

Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.

[Kito Cheng]

On Mon, May 29, 2023 at 10:53 AM Jin Ma <jinma@linux.alibaba.com> wrote:
>
> > > When testing a extension, it is often necessary for a certain program not to
> > > need some kind of extension, such as the bitmanip extension, to evaluate the
> > > performance or codesize of the extension. However, the current multilib rules
> > > will report an error when it is not a superset of the MULTILIB_REQUIRED list,
> > > which will cause the program to be unable to link normally, thus failing to
> > > achieve the expected purpose.
> >
> >  Hmm, I have troubles understanding what is going on here.  What do you
> > refer to by saying: "it is not a superset of the MULTILIB_REQUIRED list"?
>
> This is a new matching rule added by kito for the multilib of riscv:
> https://github.com/gcc-mirror/gcc/commit/d72ca12b846a9f5c01674b280b1817876c77888f
>
> >  There should be no problem with linking compiled modules together that
> > make use of different extensions, with the static linker figuring out the
> > combined set of extensions actually required at run time for the program
> > loader to consider, as long as the modules do not have contradicting
> > requirements, e.g. big vs little endianness or RV32 vs RV64.
> >
> >  Can you give me a specific example (compilation options and multilibs
> > available) of a failure you refer to?
>
> A simple example:
> 1. Use "--disable-multilib --with-abi =lp64d --with-arch =rv64imafdc_zba_zbb_zbc_zbs"
> to build the toolchain".
> 2. Use the toolchain to test the impact of zba_zbb_zbc_zbs extensions on the
> performance and codesize of some functions or files in the program.
>
> In this case, I may need to use the command "-mabi=lp64d -march=rv64imafdc" for
> the compilation of a specific .c file in the program, which will cause the link to
> fail and throw the following error: "FATAL ERROR: Can't find suitable multilib set for
> '-march=rv64imafdc'/'-mabi=lp64d'". This does not satisfy the purpose of the test.

I feel this case should be build with --with-arch =rv64imafdc and test
with -march=rv64imafdc and  -march=rv64imafdc_zba_zbb_zbc_zbs,
but anyway I am OK with option :P

>
> I think this needs an option to turn off this check. Users sometimes, just as
> gcc uses the default multilib when it does not match the appropriate multilib,
> do not need the `security lock`, and should already understand the risks
> of using this option.
>
> >  Is this something that could be solved without resorting to a possibly
> > dangerous hack, by making use of MULTILIB_REUSE?
>
> Regarding the use of MULTILIB_REUSE, I think kito's patch has already been explained
> and is currently implemented according to the new rules.
> https://github.com/gcc-mirror/gcc/commit/5ca9980fc86242505ffdaaf62bca1fd5db26550b
>
> >
> >   Maciej
>
> Thanks,
> Jin

Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.

[Jin Ma]

> > > > When testing a extension, it is often necessary for a certain program not to
> > > > need some kind of extension, such as the bitmanip extension, to evaluate the
> > > > performance or codesize of the extension. However, the current multilib rules
> > > > will report an error when it is not a superset of the MULTILIB_REQUIRED list,
> > > > which will cause the program to be unable to link normally, thus failing to
> > > > achieve the expected purpose.
> > >
> > >  Hmm, I have troubles understanding what is going on here.  What do you
> > > refer to by saying: "it is not a superset of the MULTILIB_REQUIRED list"?
> >
> > This is a new matching rule added by kito for the multilib of riscv:
> > https://github.com/gcc-mirror/gcc/commit/d72ca12b846a9f5c01674b280b1817876c77888f
> >
> > >  There should be no problem with linking compiled modules together that
> > > make use of different extensions, with the static linker figuring out the
> > > combined set of extensions actually required at run time for the program
> > > loader to consider, as long as the modules do not have contradicting
> > > requirements, e.g. big vs little endianness or RV32 vs RV64.
> > >
> > >  Can you give me a specific example (compilation options and multilibs
> > > available) of a failure you refer to?
> >
> > A simple example:
> > 1. Use "--disable-multilib --with-abi =lp64d --with-arch =rv64imafdc_zba_zbb_zbc_zbs"
> > to build the toolchain".
> > 2. Use the toolchain to test the impact of zba_zbb_zbc_zbs extensions on the
> > performance and codesize of some functions or files in the program.
> >
> > In this case, I may need to use the command "-mabi=lp64d -march=rv64imafdc" for
> > the compilation of a specific .c file in the program, which will cause the link to
> > fail and throw the following error: "FATAL ERROR: Can't find suitable multilib set for
> > '-march=rv64imafdc'/'-mabi=lp64d'". This does not satisfy the purpose of the test.
> 
> I feel this case should be build with --with-arch =rv64imafdc and test
> with -march=rv64imafdc and  -march=rv64imafdc_zba_zbb_zbc_zbs,
> but anyway I am OK with option :P

Yes, but with "--with-arch=rv64imafdc" building toolchains, the library will not contain
zba_zbb_zbc_zbs extensions, so how can we quickly and easily eliminate the impact of not
using zba_zbb_zbc_zbs extensions in a certain program on program performance and codesize?

Although-mno-multilib-check is unsafe, it is useful during the development and testing phases.

> 
> >
> > I think this needs an option to turn off this check. Users sometimes, just as
> > gcc uses the default multilib when it does not match the appropriate multilib,
> > do not need the `security lock`, and should already understand the risks
> > of using this option.
> >
> > >  Is this something that could be solved without resorting to a possibly
> > > dangerous hack, by making use of MULTILIB_REUSE?
> >
> > Regarding the use of MULTILIB_REUSE, I think kito's patch has already been explained
> > and is currently implemented according to the new rules.
> > https://github.com/gcc-mirror/gcc/commit/5ca9980fc86242505ffdaaf62bca1fd5db26550b
> >
> > >
> > >   Maciej
> >
> > Thanks,
> > Jin

Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.

[Jeff Law]

On 5/28/23 21:46, Jin Ma wrote:
>>>>> When testing a extension, it is often necessary for a certain program not to
>>>>> need some kind of extension, such as the bitmanip extension, to evaluate the
>>>>> performance or codesize of the extension. However, the current multilib rules
>>>>> will report an error when it is not a superset of the MULTILIB_REQUIRED list,
>>>>> which will cause the program to be unable to link normally, thus failing to
>>>>> achieve the expected purpose.
>>>>
>>>>   Hmm, I have troubles understanding what is going on here.  What do you
>>>> refer to by saying: "it is not a superset of the MULTILIB_REQUIRED list"?
>>>
>>> This is a new matching rule added by kito for the multilib of riscv:
>>> https://github.com/gcc-mirror/gcc/commit/d72ca12b846a9f5c01674b280b1817876c77888f
>>>
>>>>   There should be no problem with linking compiled modules together that
>>>> make use of different extensions, with the static linker figuring out the
>>>> combined set of extensions actually required at run time for the program
>>>> loader to consider, as long as the modules do not have contradicting
>>>> requirements, e.g. big vs little endianness or RV32 vs RV64.
>>>>
>>>>   Can you give me a specific example (compilation options and multilibs
>>>> available) of a failure you refer to?
>>>
>>> A simple example:
>>> 1. Use "--disable-multilib --with-abi =lp64d --with-arch =rv64imafdc_zba_zbb_zbc_zbs"
>>> to build the toolchain".
>>> 2. Use the toolchain to test the impact of zba_zbb_zbc_zbs extensions on the
>>> performance and codesize of some functions or files in the program.
>>>
>>> In this case, I may need to use the command "-mabi=lp64d -march=rv64imafdc" for
>>> the compilation of a specific .c file in the program, which will cause the link to
>>> fail and throw the following error: "FATAL ERROR: Can't find suitable multilib set for
>>> '-march=rv64imafdc'/'-mabi=lp64d'". This does not satisfy the purpose of the test.
>>
>> I feel this case should be build with --with-arch =rv64imafdc and test
>> with -march=rv64imafdc and  -march=rv64imafdc_zba_zbb_zbc_zbs,
>> but anyway I am OK with option :P
> 
> Yes, but with "--with-arch=rv64imafdc" building toolchains, the library will not contain
> zba_zbb_zbc_zbs extensions, so how can we quickly and easily eliminate the impact of not
> using zba_zbb_zbc_zbs extensions in a certain program on program performance and codesize?
> 
> Although-mno-multilib-check is unsafe, it is useful during the development and testing phases.
But I'm not sure that's a good reason to include an unsafe option like 
this in the official GCC sources.

This is the kind of thing that I'd tend to think belongs as a local change.

jeff

Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.

[Maciej W. Rozycki]

On Mon, 29 May 2023, Jin Ma wrote:

> >  Can you give me a specific example (compilation options and multilibs 
> > available) of a failure you refer to?
> 
> A simple example:
> 1. Use "--disable-multilib --with-abi =lp64d --with-arch =rv64imafdc_zba_zbb_zbc_zbs"
> to build the toolchain".
> 2. Use the toolchain to test the impact of zba_zbb_zbc_zbs extensions on the
> performance and codesize of some functions or files in the program.
> 
> In this case, I may need to use the command "-mabi=lp64d -march=rv64imafdc" for
> the compilation of a specific .c file in the program, which will cause the link to
> fail and throw the following error: "FATAL ERROR: Can't find suitable multilib set for
> '-march=rv64imafdc'/'-mabi=lp64d'". This does not satisfy the purpose of the test.

 Thank you.  This is weird and contrary to how things used to work since 
forever (not necessarily an argument by itself, but our usual arrangement 
seemed reasonable).  So whenever `--disable-multilib' has been used for 
GCC configuration I would expect all the multilib logic to be suppressed 
(as it used to be) and all assembler output just being thrown at the 
linker hoping for the best (the linker has its own logic to decide what's 
compatible enough and what's not; modulo any bugs of course).

 So has the change in semantics actually been intentional?

  Maciej

Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.

[Jeff Law]

On 5/30/23 08:48, Maciej W. Rozycki wrote:
> On Mon, 29 May 2023, Jin Ma wrote:
> 
>>>   Can you give me a specific example (compilation options and multilibs
>>> available) of a failure you refer to?
>>
>> A simple example:
>> 1. Use "--disable-multilib --with-abi =lp64d --with-arch =rv64imafdc_zba_zbb_zbc_zbs"
>> to build the toolchain".
>> 2. Use the toolchain to test the impact of zba_zbb_zbc_zbs extensions on the
>> performance and codesize of some functions or files in the program.
>>
>> In this case, I may need to use the command "-mabi=lp64d -march=rv64imafdc" for
>> the compilation of a specific .c file in the program, which will cause the link to
>> fail and throw the following error: "FATAL ERROR: Can't find suitable multilib set for
>> '-march=rv64imafdc'/'-mabi=lp64d'". This does not satisfy the purpose of the test.
> 
>   Thank you.  This is weird and contrary to how things used to work since
> forever (not necessarily an argument by itself, but our usual arrangement
> seemed reasonable).  So whenever `--disable-multilib' has been used for
> GCC configuration I would expect all the multilib logic to be suppressed
> (as it used to be) and all assembler output just being thrown at the
> linker hoping for the best (the linker has its own logic to decide what's
> compatible enough and what's not; modulo any bugs of course).
> 
>   So has the change in semantics actually been intentional?
Just as important, this scenario is not one that we really want to cater 
the compiler's behavior to.  We should not be introducing an unsafe 
option like this into the compiler sources -- engineers that need to do 
this kind of testing can carray this kind of patch in their downstream 
trees.

jeff