public inbox for openrisc@lists.librecores.org
 help / color / mirror / Atom feed
From: Stafford Horne <shorne@gmail.com>
To: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
Cc: GLIBC patches <libc-alpha@sourceware.org>,
	Linux OpenRISC <linux-openrisc@vger.kernel.org>
Subject: Re: [PATCH v2 2/3] or1k: Add hard float support
Date: Thu, 2 May 2024 21:45:59 +0100	[thread overview]
Message-ID: <ZjP7h7f2YXTPg5Vo@antec> (raw)
In-Reply-To: <625b3922-f627-4d8c-8ff9-40a21425989a@linaro.org>

On Thu, May 02, 2024 at 03:44:21PM -0300, Adhemerval Zanella Netto wrote:
> 
> 
> On 29/04/24 02:47, Stafford Horne wrote:
> > This patch adds hardware floating point support to OpenRISC.  Hardware
> > floating point toolchain builds are enabled by passing the machine
> > specific argument -mhard-float to gcc via CFLAGS.  With this enabled GCC
> > generates floating point instructions for single-precision operations
> > and exports __or1k_hard_float__.
> > 
> > There are 2 main parts to this patch.
> > 
> >  - Implement fenv functions to update the FPCSR flags keeping it in sync
> >    with sfp (software floating point).
> >  - Update machine context functions to store and restore the FPCSR
> >    state.
> > 
> > *On mcontext_t ABI*
> > 
> > This patch adds __fpcsr to mcontext_t.  This is an ABI change, but also
> > an ABI fix.  The Linux kernel has always defined padding in mcontext_t
> > that space was missing from the glibc ABI.  In Linux this unused space
> > has now been re-purposed for storing the FPCSR.  This patch brings
> > OpenRISC glibc in line with the Linux kernel and other libc
> > implementation (musl).
> > 
> > Compatibility getcontext, setcontext, etc symbols have been added to
> > allow for binaries expecting the old ABI to continue to work.
> > 
> > *Hard float ABI*
> > 
> > The calling conventions and types do not change with OpenRISC hard-float
> > so glibc hard-float builds continue to use dynamic linker
> > /lib/ld-linux-or1k.so.1.
> > 
> > *Testing*
> > 
> > I have tested this patch both with hard-float and soft-float builds and
> > the test results look fine to me.  Results are as follows:
> > 
> > Hard Float
> > 
> >     # failures
> >     FAIL: elf/tst-sprof-basic		(Haven't figured out yet, not related to hard-float)
> >     FAIL: gmon/tst-gmon-pie		(PIE bug in or1k toolchain)
> >     FAIL: gmon/tst-gmon-pie-gprof	(PIE bug in or1k toolchain)
> >     FAIL: iconvdata/iconv-test		(timeout, passed when run manually)
> >     FAIL: nptl/tst-cond24		(Timeout)
> >     FAIL: nptl/tst-mutex10		(Timeout)
> > 
> >     # summary
> > 	  6 FAIL
> >        4289 PASS
> > 	 86 UNSUPPORTED
> > 	 16 XFAIL
> > 	  2 XPASS
> > 
> >     # versions
> >     Toolchain: or1k-smhfpu-linux-gnu
> >     Compiler:  gcc version 14.0.1 20240324 (experimental) [master r14-9649-gbb04a11418f] (GCC)
> >     Binutils:  GNU assembler version 2.42.0 (or1k-smhfpu-linux-gnu) using BFD version (GNU Binutils) 2.42.0.20240324
> >     Linux:     Linux buildroot 6.9.0-rc1-00008-g4dc70e1aadfa #112 SMP Sat Apr 27 06:43:11 BST 2024 openrisc GNU/Linux
> >     Tester:    shorne
> >     Glibc:     2024-04-25 b62928f907 Florian Weimer   x86: In ld.so, diagnose missing APX support in APX-only builds  (origin/master, origin/HEAD)
> > 
> > Soft Float
> > 
> >     # failures
> >     FAIL: elf/tst-sprof-basic
> >     FAIL: gmon/tst-gmon-pie
> >     FAIL: gmon/tst-gmon-pie-gprof
> >     FAIL: nptl/tst-cond24
> >     FAIL: nptl/tst-mutex10
> > 
> >     # summary
> > 	  5 FAIL
> >        4295 PASS
> > 	 81 UNSUPPORTED
> > 	 16 XFAIL
> > 	  2 XPASS
> > 
> >     # versions
> >     Toolchain: or1k-smh-linux-gnu
> >     Compiler:  gcc version 14.0.1 20240324 (experimental) [master r14-9649-gbb04a11418f] (GCC)
> >     Binutils:  GNU assembler version 2.42.0 (or1k-smh-linux-gnu) using BFD version (GNU Binutils) 2.42.0.20240324
> >     Linux:     Linux buildroot 6.9.0-rc1-00008-g4dc70e1aadfa #112 SMP Sat Apr 27 06:43:11 BST 2024 openrisc GNU/Linux
> >     Tester:    shorne
> >     Glibc:     2024-04-25 b62928f907 Florian Weimer   x86: In ld.so, diagnose missing APX support in APX-only builds  (origin/master, origin/HEAD)
> > 
> > Documentation: https://raw.githubusercontent.com/openrisc/doc/master/openrisc-arch-1.4-rev0.pdf
> 
> The patch looks ok regarding the mcontext_t changes, the new compat
> symbol will always be provided (even for non-fp build), but it should
> be ok.  Also, ff I understand correctly, the ISA and ABI was designed 
> is a way it should not matter whether the shared library is built 
> with/without -mhard-float, so there is no need to add extra ldconfig 
> to handle possible mismatches.

Yes.

> LGTM, thanks.  Some minor nits below.

Thanks very much for the review.

...

> > +#define _FPU_CONTROL_H
> > +
> > +#ifndef __or1k_hard_float__
> > +
> > +# define _FPU_RESERVED 0xffffffff
> > +# define _FPU_DEFAULT  0x00000000
> > +# define _FPU_GETCW(cw) (cw) = 0
> > +# define _FPU_SETCW(cw) (void) (cw)
> > +
> > +#else /* __or1k_hard_float__ */
> > +
> > +/* Layout of FPCSR:
> > +
> > + +-----------+----------------------------+-----+----+
> > + |  32 - 12  | 11 10  9  8  7  6  5  4  3 | 2-1 |  0 |
> > + +-----------+----------------------------+-----+----+
> > + |  Reserved | DZ IN IV IX  Z QN SN UN OV | RM  | EE |
> > + +-----------+----------------------------+-----+----+
> > +
> 
> Not sure who useful is this diagram without much detail of what each
> bitfield means.

Let me add some more docs here, the idea is to help explain what the below masks
mean.

> > + */
> > +
> > +# define _FPU_RESERVED 0xfffff000
> > +/* Default: rounding to nearest with exceptions disabled.  */
> > +# define _FPU_DEFAULT  0
> > +/* IEEE: Same as above with exceptions enabled.  */
> > +# define _FPU_IEEE     (_FPU_DEFAULT | 1)
> > +
> > +# define _FPU_FPCSR_RM_MASK (0x3 << 1)
> > +
> > +/* Macros for accessing the hardware control word.  */
> > +# define _FPU_GETCW(cw) __asm__ volatile ("l.mfspr %0,r0,20" : "=r" (cw))
> > +# define _FPU_SETCW(cw) __asm__ volatile ("l.mtspr r0,%0,20" : : "r" (cw))
> > +
> > +#endif /* __or1k_hard_float__ */
> > +

...

> > diff --git a/sysdeps/or1k/sfp-machine.h b/sysdeps/or1k/sfp-machine.h
> > index d17fd37730..e58e683969 100644
> > --- a/sysdeps/or1k/sfp-machine.h
> > +++ b/sysdeps/or1k/sfp-machine.h
> > @@ -36,7 +36,6 @@
> >  #define _FP_MUL_MEAT_DW_Q(R,X,Y)				\
> >    _FP_MUL_MEAT_DW_4_wide(_FP_WFRACBITS_Q,R,X,Y,umul_ppmm)
> >  
> > -
> 
> Spurious new line.

Ok.

Thanks, I will fix these up and post a v3 to the list before pushing the
patches.

-Stafford

  reply	other threads:[~2024-05-02 20:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-29  5:47 [PATCH v2 0/3] OpenRISC glibc hard float support Stafford Horne
2024-04-29  5:47 ` [PATCH v2 1/3] or1k: Add hard float libm-test-ulps Stafford Horne
2024-05-02 18:44   ` Adhemerval Zanella Netto
2024-04-29  5:47 ` [PATCH v2 2/3] or1k: Add hard float support Stafford Horne
2024-05-02 18:44   ` Adhemerval Zanella Netto
2024-05-02 20:45     ` Stafford Horne [this message]
2024-04-29  5:47 ` [PATCH v2 3/3] build-many-glibcs.py: Add openrisc hard float glibc variant Stafford Horne
2024-05-02 18:46   ` Adhemerval Zanella Netto

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=ZjP7h7f2YXTPg5Vo@antec \
    --to=shorne@gmail.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-openrisc@vger.kernel.org \
    /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