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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.