public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Jin Ma" <jinma@linux.alibaba.com>
To: "Kito Cheng" <kito.cheng@gmail.com>
Cc: "gcc-patches" <gcc-patches@gcc.gnu.org>,
	"Maciej W. Rozycki" <macro@embecosm.com>,
	"jeffreyalaw" <jeffreyalaw@gmail.com>,
	"richard.sandiford" <richard.sandiford@arm.com>,
	"christoph.muellner" <christoph.muellner@vrull.eu>,
	"jinma.contrib" <jinma.contrib@gmail.com>
Subject: Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.
Date: Mon, 29 May 2023 11:46:37 +0800	[thread overview]
Message-ID: <25b40604-3608-4be4-91e9-46d5ce9ccb9a.jinma@linux.alibaba.com> (raw)
In-Reply-To: <CA+yXCZCDwVBLX+bQZETsRAJ7=MK1CXn6GSQmiA-pZDb_a5-O2g@mail.gmail.com>

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

  reply	other threads:[~2023-05-29  3:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-23  4:42 Jin Ma
2023-05-25 16:10 ` Kito Cheng
2023-05-26 13:19 ` Maciej W. Rozycki
2023-05-29  2:53   ` Jin Ma
2023-05-29  3:14     ` Kito Cheng
2023-05-29  3:46       ` Jin Ma [this message]
2023-05-29 13:02         ` Jeff Law
2023-05-30 14:48     ` Maciej W. Rozycki
2023-05-30 23:39       ` Jeff Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=25b40604-3608-4be4-91e9-46d5ce9ccb9a.jinma@linux.alibaba.com \
    --to=jinma@linux.alibaba.com \
    --cc=christoph.muellner@vrull.eu \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=jinma.contrib@gmail.com \
    --cc=kito.cheng@gmail.com \
    --cc=macro@embecosm.com \
    --cc=richard.sandiford@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).