[PATCH v3 6/8] RISC-V: Mention -mbig-endian and -mlittle-endian in doc

[Jim Wilson]

On Tue, Jan 5, 2021 at 12:02 AM Marcus Comstedt <marcus@mc.pp.se> wrote

> Well, the shorter options do exist in the sense that the longer ones
> can be abbreviated.  Documenting the abbreviations would function as
>

Having two options complicates multilib support, since now anyone who uses
the other option gets the wrong result unless we have MULTILIB_REUSE
definitions to map the one option to the other.  We already have way too
many arch variations to easily manage.  We should not make this worse by
adding option aliases.  I would prefer that we just have one documented
option name for each feature.

I looked at PPC.  In gcc they are using MULTILIB_MATCHES to handle the
multiple endian option names.  The RISC-V multilib-generator doesn't
support MULTILIB_MATCHES currently.  If we wanted to use that, we would
have to extend multilib-generator, and then verify that everything still
works, which isn't a given, considering how complicated the RISC-V
multilibs are.  We have already run into bugs in the gcc multilib support
trying to keep this working.  There would be some risk here, and some
delay, if we were forced to add MULTILIB_MATCHES support to the RISC-V
toolchain.

Also if you look in gcc you will see that the PPC port in the
rs6000/sysv4.opt file has to support both -mlittle-endian and -mlittle as
separate options as the compiler doesn't accept abbreviations like the
assembler does.  And the assembler actually supports a third option -le
which the compiler doesn't support.  I'd say this is a poor example of how
to do big/little endian support in the toolchain.

Jim