Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.
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
Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.
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.
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.
> > > > 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.
On Mon, May 29, 2023 at 10:53 AM 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 > > 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.
> > 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.
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.
> 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= 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.`
[PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.
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= 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
