add rv64im{,c,fc} multilibs

We've had customer demand for these multilibs.  We'd be happy to
maintain this change locally, but I thought I'd contribute the patch,
just in case there's wider interest in them.  WDYT?


for  gcc/ChangeLog

	* config/riscv/t-elf-multilib: Add multilibs for rv64im,
	rv64imc, and rv64imfc/lp64f.
---
 gcc/config/riscv/t-elf-multilib |   11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

Hi Alexandre:

We've added a new configure option to allow you to override that
without changing source code.

For example:
--with-multilib-generator="rv32i-ilp32--c;rv32im-ilp32--c;rv32iac-ilp32--;rv32imac-ilp32--;rv32imafc-ilp32f-rv32imafdc-;rv64im-lp64--;rv64imc-lp64--;rv64imfc-lp64f--;rv64imac-lp64--;rv64imafdc-lp64d--"

Doc:
https://gcc.gnu.org/install/configure.html

GCC Changes:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c1e6691245ca2f1f329549f323f67afe32bcb97a

On Tue, Feb 23, 2021 at 4:01 PM Alexandre Oliva <oliva@adacore.com> wrote:
>
>
> We've had customer demand for these multilibs.  We'd be happy to
> maintain this change locally, but I thought I'd contribute the patch,
> just in case there's wider interest in them.  WDYT?
>
>
> for  gcc/ChangeLog
>
>         * config/riscv/t-elf-multilib: Add multilibs for rv64im,
>         rv64imc, and rv64imfc/lp64f.
> ---
>  gcc/config/riscv/t-elf-multilib |   11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/config/riscv/t-elf-multilib b/gcc/config/riscv/t-elf-multilib
> index 19f9434616c2d..b268e26c954c8 100644
> --- a/gcc/config/riscv/t-elf-multilib
> +++ b/gcc/config/riscv/t-elf-multilib
> @@ -1,6 +1,6 @@
>  # This file was generated by multilib-generator with the command:
> -#  ./multilib-generator rv32i-ilp32--c rv32im-ilp32--c rv32iac-ilp32-- rv32imac-ilp32-- rv32imafc-ilp32f-rv32imafdc- rv64imac-lp64-- rv64imafdc-lp64d--
> -MULTILIB_OPTIONS = march=rv32i/march=rv32ic/march=rv32im/march=rv32imc/march=rv32iac/march=rv32imac/march=rv32imafc/march=rv32imafdc/march=rv32gc/march=rv64imac/march=rv64imafdc/march=rv64gc mabi=ilp32/mabi=ilp32f/mabi=lp64/mabi=lp64d
> +#  ./multilib-generator rv32i-ilp32--c rv32im-ilp32--c rv32iac-ilp32-- rv32imac-ilp32-- rv32imafc-ilp32f-rv32imafdc- rv64im-lp64-- rv64imc-lp64-- rv64imfc-lp64f-- rv64imac-lp64-- rv64imafdc-lp64d--
> +MULTILIB_OPTIONS = march=rv32i/march=rv32ic/march=rv32im/march=rv32imc/march=rv32iac/march=rv32imac/march=rv32imafc/march=rv32imafdc/march=rv32gc/march=rv64im/march=rv64imc/march=rv64imfc/march=rv64imac/march=rv64imafdc/march=rv64gc mabi=ilp32/mabi=ilp32f/mabi=lp64/mabi=lp64f/mabi=lp64d
>  MULTILIB_DIRNAMES = rv32i \
>  rv32ic \
>  rv32im \
> @@ -10,17 +10,24 @@ rv32imac \
>  rv32imafc \
>  rv32imafdc \
>  rv32gc \
> +rv64im \
> +rv64imc \
> +rv64imfc \
>  rv64imac \
>  rv64imafdc \
>  rv64gc ilp32 \
>  ilp32f \
>  lp64 \
> +lp64f \
>  lp64d
>  MULTILIB_REQUIRED = march=rv32i/mabi=ilp32 \
>  march=rv32im/mabi=ilp32 \
>  march=rv32iac/mabi=ilp32 \
>  march=rv32imac/mabi=ilp32 \
>  march=rv32imafc/mabi=ilp32f \
> +march=rv64im/mabi=lp64 \
> +march=rv64imc/mabi=lp64 \
> +march=rv64imfc/mabi=lp64f \
>  march=rv64imac/mabi=lp64 \
>  march=rv64imafdc/mabi=lp64d
>  MULTILIB_REUSE = march.rv32i/mabi.ilp32=march.rv32ic/mabi.ilp32 \
>
>
> --
> Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
>    Free Software Activist         GNU Toolchain Engineer
>         Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

On Feb 23, 2021, Kito Cheng <kito.cheng@gmail.com> wrote:

> We've added a new configure option to allow you to override that
> without changing source code.

Ah, nice, thanks!  I'll add a note on our internal patch to switch to
that when we switch to GCC 11.


I take your response as confirming my expectation that the defaults are
to remain unchanged for now, and I will thus proceed under this
assumption.

Thanks for the prompt response!

On Tue, Feb 23, 2021 at 2:17 AM Alexandre Oliva <oliva@adacore.com> wrote:

> I take your response as confirming my expectation that the defaults are
> to remain unchanged for now, and I will thus proceed under this
> assumption.
>

If we add default multilibs for you, then to be fair, we need to add
default multilibs for other people that ask, and before long we are trying
to build hundreds or maybe even thousands of multilibs by default which is
unworkable.  There are simply too many different extensions, and too many
different valid combinations of them.  A problem that is quickly getting
worse, as there are a slew of extensions that are planned for final
approval this year.  The current set was defined before I started doing
RISC-V work over 3 years ago, and I've been saying no to everyone that
wants to change the default set.  The current set is tractable for newbies
to try to build and use.  People that want a different set can define their
own, and we have made it easy for people to define their own sets of
multilibs as Kito pointed out.

I do think that when the architecture profiles are adopted and implemented
it would make sense to add them to the default set, and maybe eventually
replace the default set.

Jim

On Feb 23, 2021, Jim Wilson <jimw@sifive.com> wrote:

> If we add default multilibs for you, then to be fair, we need to add
> default multilibs for other people that ask, and before long we are trying
> to build hundreds or maybe even thousands of multilibs by default which is
> unworkable.

*nod*, it's a very familiar issue to me, I know where that's coming
from, no worries.  I expected the change would be turned down, and for
good reason, unless there was say an emerging growth of adoption on
those multilibs, which I wasn't aware of.  The expectation didn't stop
me from offering the patch just in case, that's all.

> People that want a different set can define their own, and we have
> made it easy for people to define their own sets of multilibs as Kito
> pointed out.

*nod*, thanks,

On Feb 24, 2021, at 1:10 AM, Alexandre Oliva <oliva@adacore.com> wrote:
> 
> On Feb 23, 2021, Jim Wilson <jimw@sifive.com> wrote:
>> If we add default multilibs for you
> 
> *nod*, it's a very familiar issue to me, I know where that's coming
> from, no worries.

So, what I'd do is if you have a triplet component that isn't used much, say, the middle one, you can embed the vendor there, and use the vendor to trigger which multilib set you want.

i386-unknown-linux

becomes

i386-telcovendor2-linux

and then telcovendor2 selects new multilib set.  The generic port, selects the base multilib set, and no one, other then a vendor build would select the vendor set.

That's one solution, there are others.  For example, on a system, you can smell the previously installed multilib set, and default to building those.