Re: [PATCH] Add "riscv" as an alias for "riscv32"

[Palmer Dabbelt]

I like the idea of forcing an explicit target declaration for our cross 
compilers -- it's stronger than even just "riscv-*" needs it, as "riscv32-*" 
isn't sufficient to determine the target.  This behavior manifests because the 
RISC-V ISA is defined as a set of base ISAs along with a set of extensions.  
The base ISAs are

* rv32e: 16 integer registers, each of 32 bits
* rv32i: 32 integer registers, each of 32 bits
* rv64i: 32 integer registers, each of 64 bits

and the currently defined user-mode extensions are

* m: Adds multiplication and division instructions
* a: Adds atomic operations (lr/sc and various AMOs)
* f: Adds 32 single precision registers along with single-precision 
 instructions
* d: Extends the F register set to double precision and adds the corresponding 
 instructions.
* c: Adds compressed versions of many common instructions

We express this to the compiler using the "-march" argument, via a string that 
looks something like "-march=rv64imafdc", which controls the instructions 
available for code generation.  We also have an ABI selection argument, -mabi, 
which allows users to select the calling convention used (this exists to allow 
things like Intel's x32 and ARM's softfloat/softfp/hardfp).  There's a third 
argument, -mtune, that controls how to tune for a particular microarchitecture.

Toolchains will default to one {-march, -mabi, -mtune} value, which is a 
compile-time setting.  binutils and GCC always support code generation for all 
legal {-march, -mabi, -mtune} settings, but a multilib toolchain is necessary 
to have multiple libc/libgccs (and even then we limit this to the commonly used 
settings, as otherwise there would be hundreds).  The current scheme is that 
"riscv32-*" defaults to some rv32i-based target and "riscv64-*" defaults to 
some rv64i-based target, but nothing tells you which one.  The currently 
appearing "riscv-*" binaries might default to rv32i or rv64i depending on who 
produced it.

We originally kicked around the idea of calling the targets "riscv32imac-*", 
but when we ended up with the mostly orthogonal -mabi and -mtune arguments we 
decided to give up as a tuple like "riscv32imacilp32rocket-*" seemed just too 
insane to deal with.  As a result we just tell users that they should always 
fully specify {-march, -mabi, -mtune} when cross compiling, and that build 
systems should just ignore the tuple as it doesn't really mean anything.

I'd like to keep the behavior for native compilers where the default target is 
the native host, as otherwise we'll end up with unnecessary arguments floating 
around everywhere.

I've written a blog post about our target compiler options if you're interested

   https://www.sifive.com/blog/2017/08/14/all-aboard-part-1-compiler-args/

Sorry if that's a bit too much detail...

On Thu, 21 Jun 2018 11:46:21 PDT (-0700), address@hidden wrote:
> Ah OK. So this boils down to the difference between configs for targets
> and configs for toolchains. Configs for targets should be precise as
> possible [1], and `riscv-*` makes no sense. Configs for tools are
> actually the *set* of configs the tool targets and so `riscv-` does
> indeed make make perfect sense [2]. So we can add a flag to gnu config
> (with sensible default) to only allow stuff like this for the latter
> tool case. We could also choose to add another shell script answering
> "does (tool) config a cover config b", codifying that relation. I would
> volunteer to do both of these things if a RISC-V person can give me a
> table with the intend relation.
>
> I agree with the gist of what Earnie says. To preserve symmetry and not
> surprise the user with weird defaults, I'd say a `riscv-*` tool-chain
> shouldn't default to 32-bit, 64-bit, or anything else. So the `-m64` or
> whatever is required. Or perhaps to make native compilation a bit easier
> a RISC-V tool chain should *only* default to a specific variant of
> RISC-V if that platform is the host platform, so cross compilation must
> be explicit, but native compilation with explicit-config tools can be
> implicit.
>
> John
>
> [1] Configs for targets are more known with LLVM than GNU tools, and
> their `-target` flag. But certain GNU binutils (e.g. objdump) do support
> `--target` so it's not just an LLVMism.
> [2] Yet another example of autotools and friends forcing a single target
> platform muddying the waters.
>
> On 06/21/18 13:49, Earnie wrote:
> > On 6/20/2018 7:55 PM, Palmer Dabbelt wrote:
> > > The one saving grace here is that most of the RISC-V toolchains support
> > > generating code for all targets -- in other words "riscv32-*-gcc
> > > -march=rv64gc" is a valid thing to do, and will generate 64-bit code
> > > (and links against a 64-bit libc).  As a result, none of this actually
> > > matters.
> > Given this I can understand the frustration of needing the 32/64
> > specifier.  I would then suggest the patch removes riscv32 and riscv64
> > specifics and use riscv* instead.  I.E. use riscv*-* as the filter.