Re: RFC: remove the "tile" architecture from glibc

[Joseph Myers <joseph@codesourcery.com>]

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 
and double).

> math/test-double-ceil
> math/test-double-finite-ceil
> math/test-double-finite-floor
> math/test-double-floor
> - 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
joseph@codesourcery.com