[v2,01/15] RISC-V: Build Infastructure

This patch lays out the top-level orginazition of the RISC-V port.  It
contains all the Implies files as well as various other fragments of
build infastructure for the RISC-V port.  This contains the only change
to a shared file: config.h.in.

RISC-V is a family of base ISAs with optional extensions.  The base ISAs
are RV32I and RV64I, which are 32-bit and 64-bit integer-only ISAs.
Support for these live in sysdeps/riscv/rv{32,64}.  In addition to these
ISAs, our glibc port supports most of the currently-defined extensions:
the A extension for atomics, the M extension for multiplication, the C
extension for compressed instructions, and the F/D extensions for
single/double precision IEEE floating-point.  Most of these extensions
are handled by GCC, but glibc defines various floating-point wrappers
(in sysdeps/riscv/rv{32,64}/rv{f,d}) and emulation routines (in
sysdeps/riscv/soft-fp).

We support running glibc-based programs on Linux, the suppor for which
lives in sysdeps/unix/sysv/linux/riscv.
---
 config.h.in                                  |   5 +
 nptl/Makefile                                |   4 +
 sysdeps/riscv/Implies                        |   5 +
 sysdeps/riscv/Makefile                       |  49 +++++++
 sysdeps/riscv/Versions                       |   4 +
 sysdeps/riscv/configure                      |   5 +
 sysdeps/riscv/configure.ac                   |   4 +
 sysdeps/riscv/nptl/Makefile                  |  26 ++++
 sysdeps/riscv/preconfigure                   |  54 +++++++
 sysdeps/riscv/rv32/Implies-after             |   1 +
 sysdeps/riscv/rv32/rvd/Implies               |   2 +
 sysdeps/riscv/rv32/rvf/Implies               |   1 +
 sysdeps/riscv/rv64/Implies-after             |   1 +
 sysdeps/riscv/rv64/rvd/Implies               |   3 +
 sysdeps/riscv/rv64/rvf/Implies               |   1 +
 sysdeps/unix/sysv/linux/riscv/Implies        |   1 +
 sysdeps/unix/sysv/linux/riscv/Makefile       | 100 +++++++++++++
 sysdeps/unix/sysv/linux/riscv/Versions       |   5 +
 sysdeps/unix/sysv/linux/riscv/configure      | 210 +++++++++++++++++++++++++++
 sysdeps/unix/sysv/linux/riscv/configure.ac   |  33 +++++
 sysdeps/unix/sysv/linux/riscv/rv32/Implies   |   3 +
 sysdeps/unix/sysv/linux/riscv/rv64/Implies   |   3 +
 sysdeps/unix/sysv/linux/riscv/rv64/Makefile  |   4 +
 sysdeps/unix/sysv/linux/riscv/shlib-versions |  17 +++
 24 files changed, 541 insertions(+)
 create mode 100644 sysdeps/riscv/Implies
 create mode 100644 sysdeps/riscv/Makefile
 create mode 100644 sysdeps/riscv/Versions
 create mode 100644 sysdeps/riscv/configure
 create mode 100644 sysdeps/riscv/configure.ac
 create mode 100644 sysdeps/riscv/nptl/Makefile
 create mode 100644 sysdeps/riscv/preconfigure
 create mode 100644 sysdeps/riscv/rv32/Implies-after
 create mode 100644 sysdeps/riscv/rv32/rvd/Implies
 create mode 100644 sysdeps/riscv/rv32/rvf/Implies
 create mode 100644 sysdeps/riscv/rv64/Implies-after
 create mode 100644 sysdeps/riscv/rv64/rvd/Implies
 create mode 100644 sysdeps/riscv/rv64/rvf/Implies
 create mode 100644 sysdeps/unix/sysv/linux/riscv/Implies
 create mode 100644 sysdeps/unix/sysv/linux/riscv/Makefile
 create mode 100644 sysdeps/unix/sysv/linux/riscv/Versions
 create mode 100755 sysdeps/unix/sysv/linux/riscv/configure
 create mode 100644 sysdeps/unix/sysv/linux/riscv/configure.ac
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/Implies
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv64/Implies
 create mode 100644 sysdeps/unix/sysv/linux/riscv/rv64/Makefile
 create mode 100644 sysdeps/unix/sysv/linux/riscv/shlib-versions

On Tue, Dec 19, 2017 at 11:20:08PM -0800, Palmer Dabbelt wrote:
> This patch lays out the top-level orginazition of the RISC-V port.  It
> contains all the Implies files as well as various other fragments of
> build infastructure for the RISC-V port.  This contains the only change
> to a shared file: config.h.in.
[...]
>  config.h.in                                  |   5 +
>  nptl/Makefile                                |   4 +

Well, nptl/Makefile is a shared file, too.

[...]
> diff --git a/nptl/Makefile b/nptl/Makefile
> index 60d036a1ea42..f62d19febf1d 100644
> --- a/nptl/Makefile
> +++ b/nptl/Makefile
> @@ -611,6 +611,10 @@ else
>  librt = $(common-objpfx)rt/librt.a
>  endif
>  
> +# `make check' sometimes triggers a rebuild of librt.so using this Makefile,
> +# which ignores librt's dependence on libpthread
> +$(common-objpfx)rt/librt.so: $(shared-thread-library)
> +
>  $(objpfx)tst-cancel17: $(librt)
>  $(objpfx)tst-cancelx17: $(librt)
>  $(objpfx)tst-_res1mod2.so: $(objpfx)tst-_res1mod1.so

In fact, this looks like a fix unrelated to the RISC-V port.
If this is really the case, please submit the fix separately.

Thanks,

On Tue, 19 Dec 2017, Palmer Dabbelt wrote:

> diff --git a/sysdeps/riscv/Makefile b/sysdeps/riscv/Makefile
> new file mode 100644
> index 000000000000..64060531a1d5
> --- /dev/null
> +++ b/sysdeps/riscv/Makefile
> @@ -0,0 +1,49 @@
> +ifneq ($(all-rtld-routines),)
> +CFLAGS-rtld.c += -mno-plt

My previous comments from 
<https://sourceware.org/ml/libc-alpha/2017-06/msg00645.html> still apply: 
this is too fragile (people won't think when making an 
architecture-independent change about whether it needs a RISC-V-specific 
change here) and completely lacking the required detailed explanatory 
comment of what the issue is and the logic for determining what files need 
this option (but really the logic should be implemented to avoid an 
architecture-specific list of architecture-independent files being needed 
at all).

> diff --git a/sysdeps/riscv/Versions b/sysdeps/riscv/Versions
> new file mode 100644
> index 000000000000..aafa348a2395
> --- /dev/null
> +++ b/sysdeps/riscv/Versions
> @@ -0,0 +1,4 @@
> +libc {
> +  GLIBC_2.27 {
> +  }
> +}

You shouldn't need this file at all when there aren't any versions to 
include in it.

> diff --git a/sysdeps/riscv/preconfigure b/sysdeps/riscv/preconfigure

Does your soft-float lack support for exceptions and rounding modes?  If 
so, I'd expect a setting of with_fp_cond, and a corresponding nofpu 
directory or directories with Implies files pointing to ieee754/soft-fp 
(arranged so that always comes before the other ieee754/ directories in 
the sysdeps directory ordering).  That's needed to get the soft-fp 
versions of fmaf/fma/fmal used instead of the default ones relying on 
exceptions and rounding modes, so its absence should show up as test 
failures for soft-float configurations.  In future it will also similarly 
be needed to get soft-fp versions of TS 18661-1 narrowing functions used.

Remark: it makes sense for ieee754/dbl-64/wordsize-64 to be used (before 
ieee754/dbl-64 in the sysdeps directory ordering) in configurations with 
64-bit registers (but that's just an optimization so you may wish to defer 
it).

> +abi-ilp32-options     := -D__SIZEOF_INT__=4

abi-* options variables are no longer used with the current bits/syscall.h 
generation mechanism, so you should remove all settings of such variables 
from the patch.

> diff --git a/sysdeps/unix/sysv/linux/riscv/rv64/Makefile b/sysdeps/unix/sysv/linux/riscv/rv64/Makefile
> new file mode 100644
> index 000000000000..cb60d740476d
> --- /dev/null
> +++ b/sysdeps/unix/sysv/linux/riscv/rv64/Makefile
> @@ -0,0 +1,4 @@
> +ifeq ($(subdir),socket)
> +CFLAGS-recv.c += -fexceptions
> +CFLAGS-send.c += -fexceptions
> +endif

I wonder if this should be made generic for all Linux ports (and removed 
from the mips64 Makefile as well as here).

Another observation:

Since you're using ldbl-128, that presumably means _Float128 and _Float64x 
type names are supported with the same format as long double.  So you need 
to add RISC-V to the list in manual/math.texi of ports for which those 
type names and associated interfaces are supported.

I don't think you strictly need to add it to the similar lists for 
_Float128 and _Float64x support in the NEWS section for glibc 2.27, since 
the whole port is new rather than this being a new feature for an existing 
port in the RISC-V case.  However, the patch series needs to include a 
patch adding a NEWS item about the port, and the port also needs to be 
added to the list in the README file of supported glibc configurations 
using the Linux kernel.

On 20/12/2017 14:21, Joseph Myers wrote:
> On Tue, 19 Dec 2017, Palmer Dabbelt wrote:

>> diff --git a/sysdeps/unix/sysv/linux/riscv/rv64/Makefile b/sysdeps/unix/sysv/linux/riscv/rv64/Makefile
>> new file mode 100644
>> index 000000000000..cb60d740476d
>> --- /dev/null
>> +++ b/sysdeps/unix/sysv/linux/riscv/rv64/Makefile
>> @@ -0,0 +1,4 @@
>> +ifeq ($(subdir),socket)
>> +CFLAGS-recv.c += -fexceptions
>> +CFLAGS-send.c += -fexceptions
>> +endif
> 
> I wonder if this should be made generic for all Linux ports (and removed 
> from the mips64 Makefile as well as here).
> 

We already a CFLAGS-recv.c with "-fexceptions -fasynchronous-unwind-tables"
for nptl, and I think we should add it for io as well. Could you send a
separately fix along with the mips64 cleanup?

On Wed, 20 Dec 2017 06:05:20 PST (-0800), ldv@altlinux.org wrote:
> On Tue, Dec 19, 2017 at 11:20:08PM -0800, Palmer Dabbelt wrote:
>> This patch lays out the top-level orginazition of the RISC-V port.  It
>> contains all the Implies files as well as various other fragments of
>> build infastructure for the RISC-V port.  This contains the only change
>> to a shared file: config.h.in.
> [...]
>>  config.h.in                                  |   5 +
>>  nptl/Makefile                                |   4 +
>
> Well, nptl/Makefile is a shared file, too.
>
> [...]
>> diff --git a/nptl/Makefile b/nptl/Makefile
>> index 60d036a1ea42..f62d19febf1d 100644
>> --- a/nptl/Makefile
>> +++ b/nptl/Makefile
>> @@ -611,6 +611,10 @@ else
>>  librt = $(common-objpfx)rt/librt.a
>>  endif
>>  
>> +# `make check' sometimes triggers a rebuild of librt.so using this Makefile,
>> +# which ignores librt's dependence on libpthread
>> +$(common-objpfx)rt/librt.so: $(shared-thread-library)
>> +
>>  $(objpfx)tst-cancel17: $(librt)
>>  $(objpfx)tst-cancelx17: $(librt)
>>  $(objpfx)tst-_res1mod2.so: $(objpfx)tst-_res1mod1.so
>
> In fact, this looks like a fix unrelated to the RISC-V port.
> If this is really the case, please submit the fix separately.
>
> Thanks,

Oh, sorry, that must have snuck in somehow after I wrote the commit message -- 
I did a lot of rebasing.  We noticed this bug when running the test suite, I 
think Andrew must have fixed it because I was still using a workaround.

Thanks for catching this, I'll submit a patch that's pulled out from our port.

Sorry it took a while to get back to you, I've been working through the test 
suite failures.

On Wed, 20 Dec 2017 08:21:55 PST (-0800), joseph@codesourcery.com wrote:
> On Tue, 19 Dec 2017, Palmer Dabbelt wrote:
>
>> diff --git a/sysdeps/riscv/Makefile b/sysdeps/riscv/Makefile
>> new file mode 100644
>> index 000000000000..64060531a1d5
>> --- /dev/null
>> +++ b/sysdeps/riscv/Makefile
>> @@ -0,0 +1,49 @@
>> +ifneq ($(all-rtld-routines),)
>> +CFLAGS-rtld.c += -mno-plt
>
> My previous comments from
> <https://sourceware.org/ml/libc-alpha/2017-06/msg00645.html> still apply:
> this is too fragile (people won't think when making an
> architecture-independent change about whether it needs a RISC-V-specific
> change here) and completely lacking the required detailed explanatory
> comment of what the issue is and the logic for determining what files need
> this option (but really the logic should be implemented to avoid an
> architecture-specific list of architecture-independent files being needed
> at all).

Ah, sorry, I missed that from last time.  I thought we were doing this because 
we couldn't call via the PLT in ld.so because they hadn't been resolved yet, 
but as far as I can tell there's something else handling this.  I just ran into 
it when looking at the check-localplt stuff (I'm currently going through the 
test suites).

Andrew would know for sure what's going on here -- this has been in our port 
since ~2011 (when he added PLT support) and has never had an explanation.  I 
feel like it's defunct: when I remove it we end up with only the PLT entries 
listed in check-localplt, I'd expect a lot more if everything was really 
emitting PLT calls.  I can't figure out what's actually preventing ld.so from 
using PLT calls on the _dl_fixup codepath.

I assume I'm missing something here?

>
>> diff --git a/sysdeps/riscv/Versions b/sysdeps/riscv/Versions
>> new file mode 100644
>> index 000000000000..aafa348a2395
>> --- /dev/null
>> +++ b/sysdeps/riscv/Versions
>> @@ -0,0 +1,4 @@
>> +libc {
>> +  GLIBC_2.27 {
>> +  }
>> +}
>
> You shouldn't need this file at all when there aren't any versions to
> include in it.

IIRC some test was depending on this.  I've filled all the machines with builds 
right now, but I'll give it another look later tonight.  I've got two small 
patches that touch shared build system stuff already.

>> diff --git a/sysdeps/riscv/preconfigure b/sysdeps/riscv/preconfigure
>
> Does your soft-float lack support for exceptions and rounding modes?  If
> so, I'd expect a setting of with_fp_cond, and a corresponding nofpu
> directory or directories with Implies files pointing to ieee754/soft-fp
> (arranged so that always comes before the other ieee754/ directories in
> the sysdeps directory ordering).  That's needed to get the soft-fp
> versions of fmaf/fma/fmal used instead of the default ones relying on
> exceptions and rounding modes, so its absence should show up as test
> failures for soft-float configurations.  In future it will also similarly
> be needed to get soft-fp versions of TS 18661-1 narrowing functions used.

If I understand what's going on correctly here, we support exceptions in the 
soft float ABI when built with hardware floating point instructions, but 
otherwise we don't (we're always round nearest).  I believe that means we need 
to set "with_fp_cond=1" when building with hardware floating point (regardless 
of ABI), and "with_fp_cond=0" otherwise.

Does this look sane?

diff --git a/sysdeps/riscv/preconfigure b/sysdeps/riscv/preconfigure
index e118a5ed28f6..6f2bc20ecd5b 100644
--- a/sysdeps/riscv/preconfigure
+++ b/sysdeps/riscv/preconfigure
@@ -16,12 +16,15 @@ riscv*)
     case "$flen" in
     64)
        float_machine=rvd
+       with_fp_cond=1
        ;;
     32)
        float_machine=rvf
+       with_fp_cond=1
        ;;
     "")
        float_machine=
+       with_fp_cond=0
        ;;
     *)
        echo "Unable to determine FLEN" >&2


> Remark: it makes sense for ieee754/dbl-64/wordsize-64 to be used (before
> ieee754/dbl-64 in the sysdeps directory ordering) in configurations with
> 64-bit registers (but that's just an optimization so you may wish to defer
> it).
>
>> +abi-ilp32-options     := -D__SIZEOF_INT__=4
>
> abi-* options variables are no longer used with the current bits/syscall.h
> generation mechanism, so you should remove all settings of such variables
> from the patch.

OK, we'll remove them for the v3.

>
>> diff --git a/sysdeps/unix/sysv/linux/riscv/rv64/Makefile b/sysdeps/unix/sysv/linux/riscv/rv64/Makefile
>> new file mode 100644
>> index 000000000000..cb60d740476d
>> --- /dev/null
>> +++ b/sysdeps/unix/sysv/linux/riscv/rv64/Makefile
>> @@ -0,0 +1,4 @@
>> +ifeq ($(subdir),socket)
>> +CFLAGS-recv.c += -fexceptions
>> +CFLAGS-send.c += -fexceptions
>> +endif
>
> I wonder if this should be made generic for all Linux ports (and removed
> from the mips64 Makefile as well as here).

I think we got it from MIPS, but it doesn't seem like it should be ISA 
dependent.  I'm afraid this is another thing that's been there since before I 
was around, but I feel like since it's not in anyone else's port it's safe to 
drop it from ours.

Thanks for reviewing our code, and sorry it's a bit of a mess.  I'll try and 
get something a bit more sane out for a v3, but I'm afraid it might take a few 
more days -- luckily with the weekend and Christmas I should have some time to 
actually work on this :).

On Wed, 20 Dec 2017 08:43:18 PST (-0800), joseph@codesourcery.com wrote:
> Another observation:
>
> Since you're using ldbl-128, that presumably means _Float128 and _Float64x
> type names are supported with the same format as long double.  So you need
> to add RISC-V to the list in manual/math.texi of ports for which those
> type names and associated interfaces are supported.

That's our intent.  How does this look?

diff --git a/manual/math.texi b/manual/math.texi
index a9f2a9813832..d19a14b47dc3 100644
--- a/manual/math.texi
+++ b/manual/math.texi
@@ -70,7 +70,7 @@ provided for @code{_Float32}, @code{_Float64} and @code{_Float32x} on
 all platforms.
 It is also provided for @code{_Float128} and @code{_Float64x} on
 powerpc64le (PowerPC 64-bits little-endian), x86_64, x86, ia64,
-aarch64, alpha, mips64, s390 and sparc.
+aarch64, alpha, mips64, riscv, s390 and sparc.

 @menu
 * Mathematical Constants::      Precise numeric values for often-used

> I don't think you strictly need to add it to the similar lists for
> _Float128 and _Float64x support in the NEWS section for glibc 2.27, since
> the whole port is new rather than this being a new feature for an existing
> port in the RISC-V case.  However, the patch series needs to include a
> patch adding a NEWS item about the port, and the port also needs to be
> added to the list in the README file of supported glibc configurations
> using the Linux kernel.

How does this look?

commit 462ad608e82fa7a4c340f05dc6c300610282d8d9
Author: Palmer Dabbelt <palmer@dabbelt.com>
Date:   Fri Dec 22 19:33:57 2017 -0800

    NEWS and README

diff --git a/NEWS b/NEWS
index a43ff26e83cf..a7476265ca9e 100644
--- a/NEWS
+++ b/NEWS
@@ -40,13 +40,13 @@ Major new features:
   process aborts as the result of assertion failures.

 * On platforms where long double has the IEEE binary128 format (aarch64,
-  alpha, mips64, s390 and sparc), the math library now implements _Float128
-  interfaces for that type, as defined by ISO/IEC TS 18661-3:2015.  These
-  are the same interfaces added in version 2.26 for some platforms where
+  alpha, mips64, riscv, s390 and sparc), the math library now implements
+  _Float128 interfaces for that type, as defined by ISO/IEC TS 18661-3:2015.
+  These are the same interfaces added in version 2.26 for some platforms where
   this format is supported but is not the format of long double.

 * On platforms with support for _Float64x (aarch64, alpha, i386, ia64,
-  mips64, powerpc64le, s390, sparc and x86_64), the math library now
+  mips64, powerpc64le, riscv, s390, sparc and x86_64), the math library now
   implements interfaces for that type, as defined by ISO/IEC TS
   18661-3:2015.  These are corresponding interfaces to those supported for
   _Float128.
@@ -67,6 +67,17 @@ Major new features:
   collation ordering.  Previous glibc versions used locale-specific
   ordering, the change might break systems that relied on that.

+* Support for the RISC-V ISA running on Linux has been added.  This port
+  requires at least binutils-2.30, gcc-7.3.0, and linux-4.15; and is supported
+  for the following ISA and ABI pairs:
+
+    - rv32imac ilp32
+    - rv32imafdc ilp32
+    - rv32imafdc ilp32d
+    - rv64imac lp64
+    - rv64imafdc lp64
+    - rv64imafdc lp64d
+
 Deprecated and removed features, and other changes affecting compatibility:

 * On GNU/Linux, the obsolete Linux constant PTRACE_SEIZE_DEVEL is no longer
diff --git a/README b/README
index c3d17d137887..4ab2bfc6f4c4 100644
--- a/README
+++ b/README
@@ -39,6 +39,8 @@ The GNU C Library supports these configurations for using Linux kernels:
 	powerpc64*-*-linux-gnu	Big-endian and little-endian.
 	s390-*-linux-gnu
 	s390x-*-linux-gnu
+	riscv32-*-linux-gnu
+	riscv64-*-linux-gnu
 	sh[34]-*-linux-gnu
 	sparc*-*-linux-gnu
 	sparc64*-*-linux-gnu

On Fri, 22 Dec 2017, Palmer Dabbelt wrote:

> If I understand what's going on correctly here, we support exceptions in the
> soft float ABI when built with hardware floating point instructions, but
> otherwise we don't (we're always round nearest).  I believe that means we need
> to set "with_fp_cond=1" when building with hardware floating point (regardless
> of ABI), and "with_fp_cond=0" otherwise.
> 
> Does this look sane?

Yes, but it needs to go along with having a nofpu sysdeps directory or 
directories with an Implies file or files pointing to ieee754/soft-fp 
(make sure that the soft-float configurations do end up with 
ieee754/soft-fp before other ieee754 directories in their sysdeps 
directory ordering).

> > > +abi-ilp32-options     := -D__SIZEOF_INT__=4
> > 
> > abi-* options variables are no longer used with the current bits/syscall.h
> > generation mechanism, so you should remove all settings of such variables
> > from the patch.
> 
> OK, we'll remove them for the v3.

To be clear, abi-*-condition variables are still needed (used in 
generating gnu/lib-names.h, for example); it's just abi-*-options that are 
obsolete.

On Fri, 22 Dec 2017, Palmer Dabbelt wrote:

> On Wed, 20 Dec 2017 08:43:18 PST (-0800), joseph@codesourcery.com wrote:
> > Another observation:
> > 
> > Since you're using ldbl-128, that presumably means _Float128 and _Float64x
> > type names are supported with the same format as long double.  So you need
> > to add RISC-V to the list in manual/math.texi of ports for which those
> > type names and associated interfaces are supported.
> 
> That's our intent.  How does this look?

This seems reasonable.

> How does this look?

Likewise.

On Sat, 23 Dec 2017 04:44:28 PST (-0800), joseph@codesourcery.com wrote:
> On Fri, 22 Dec 2017, Palmer Dabbelt wrote:
>
>> If I understand what's going on correctly here, we support exceptions in the
>> soft float ABI when built with hardware floating point instructions, but
>> otherwise we don't (we're always round nearest).  I believe that means we need
>> to set "with_fp_cond=1" when building with hardware floating point (regardless
>> of ABI), and "with_fp_cond=0" otherwise.
>>
>> Does this look sane?
>
> Yes, but it needs to go along with having a nofpu sysdeps directory or
> directories with an Implies file or files pointing to ieee754/soft-fp
> (make sure that the soft-float configurations do end up with
> ieee754/soft-fp before other ieee754 directories in their sysdeps
> directory ordering).

OK.  I think we might need to reorganize our directories a bit to do that, but 
I'll try and figure something sane out.

>> > > +abi-ilp32-options     := -D__SIZEOF_INT__=4
>> >
>> > abi-* options variables are no longer used with the current bits/syscall.h
>> > generation mechanism, so you should remove all settings of such variables
>> > from the patch.
>>
>> OK, we'll remove them for the v3.
>
> To be clear, abi-*-condition variables are still needed (used in
> generating gnu/lib-names.h, for example); it's just abi-*-options that are
> obsolete.

Thanks -- I noticed that when going through the commit history to see what 
other ports had done here.

On Mon, 25 Dec 2017, Palmer Dabbelt wrote:

> > Yes, but it needs to go along with having a nofpu sysdeps directory or
> > directories with an Implies file or files pointing to ieee754/soft-fp
> > (make sure that the soft-float configurations do end up with
> > ieee754/soft-fp before other ieee754 directories in their sysdeps
> > directory ordering).
> 
> OK.  I think we might need to reorganize our directories a bit to do that, but
> I'll try and figure something sane out.

I don't think you need much reorganization.  Possible just adding 
sysdeps/riscv/nofpu/Implies will suffice.  If it doesn't - if the sysdeps 
directory ordering ends up placing ieee754/soft-fp too late - then maybe 
you need a few sysdeps/riscv/<something>/nofpu/Implies files instead (as 
with MIPS, which has three such files).