This is the mail archive of the
mailing list for the glibc project.
Re: RFC: remove the "tile" architecture from glibc
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: <libc-alpha at sourceware dot org>, Jason Duerstock <jason dot duerstock at gmail dot com>, John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin dot de>, James Clarke <jrtc27 at jrtc27 dot com>
- Date: Thu, 1 Feb 2018 17:51:55 +0000
- Subject: Re: RFC: remove the "tile" architecture from glibc
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <firstname.lastname@example.org> <alpine.DEB.email@example.com> <firstname.lastname@example.org> <alpine.DEB.email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <alpine.DEB.email@example.com> <firstname.lastname@example.org>
On Thu, 1 Feb 2018, Adhemerval Zanella wrote:
> On 01/02/2018 11:39, Joseph Myers wrote:
> > On Thu, 1 Feb 2018, Adhemerval Zanella wrote:
> >> However the math tests seems to shows a lot of corner cases issues which
> >> has been fixed in generic implementations. As I commented with Jason Duerstock,
> >> John Paul Adrian, and James Clarke in a private thread I think easier solution
> >> for 2.28 is we remove the arch-specific faulty ia64 math implementation and
> >> use the generic ones. If performance is an issue we reimplement and fixed
> >> them if it is the case.
> > (a) Note that various functions don't have a generic ldbl-96
> > implementation, because all of x86_64, i386, ia64 and m68k have
> > architecture-specific implementations. So in those cases you can't simply
> > remove the ia64 implementation because there isn't an alternative one.
> My idea is to focus first on flt-32 and dbl-64 ones to check how many
> failures we can remove by using generic implementations.
How helpful that is may depend, in cases where there's no generic ldbl-96
version, on whether the bugs and implementations are essentially the same
as in the long double functions (if essentially the same and there's no
generic ldbl-96 version of that function, fixing the ia64 long double
version may give you a fix that's very similar to what's needed for float
> - Setting inexact
I should point out that ia64 has four fpsr status fields, and that
floating-point instructions can choose which status field to use.
Furthermore, the ABI specifies "Status Fields 2 and 3. The control bits in
these status fields must agree with the control bits in status field 0,
and the trap disable bits should always be set at procedure calls and
returns. The flag bits are always available for scratch use.".
I.e., for these functions setting spurious exceptions, you should just be
able to change whatever instructions might set exceptions to set those
exceptions in sf2 or sf3 instead. (Or if round-to-nearest is wanted
internally, sf1 can be used, as its flag bits are also scratch - many of
the functions do already use sf1 on most of their computations.)
On the other hand, if the functions are explicitly setting inexact - which
in fact appears to be the case for these functions - then the code that is
only there to set inexact can be removed.
Joseph S. Myers