[07/21] ARC: math soft float support

  Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
---
 ChangeLog                                |  6 +++
 sysdeps/arc/bits/fenv.h                  | 92 ++++++++++++++++++++++++++++++++
 sysdeps/arc/math_private.h               |  6 +++
 sysdeps/arc/nofpu/Implies                |  1 +
 sysdeps/arc/nofpu/math-tests-exception.h | 27 ++++++++++
 sysdeps/arc/nofpu/math-tests-rounding.h  | 27 ++++++++++
 sysdeps/arc/sfp-machine.h                | 51 ++++++++++++++++++
 7 files changed, 210 insertions(+)
 create mode 100644 sysdeps/arc/bits/fenv.h
 create mode 100644 sysdeps/arc/math_private.h
 create mode 100644 sysdeps/arc/nofpu/Implies
 create mode 100644 sysdeps/arc/nofpu/math-tests-exception.h
 create mode 100644 sysdeps/arc/nofpu/math-tests-rounding.h
 create mode 100644 sysdeps/arc/sfp-machine.h
  

On Tue, 18 Dec 2018, Vineet Gupta wrote:

> +#if defined(__ARC_FPU_SP__) || defined(__ARC_FPU_DP__)

Missing spaces before '(' (should have such spaces in most cases between 
an identifier or keyword and '(' - calls to "defined", calls to functions, 
calls to macros, __attribute__, etc. - except for a few cases of calls to 
macros such as ElfW where the result is logically used like an 
identifier).

> +/* In the soft-float case, only rounding to nearest is supported, with
> +   no exceptions.  */

To confirm: hard-float and soft-float are always different ABIs; you don't 
support hard-float compilation using the soft-float function calling ABI 
(like is supported for ARM and RISC-V, for example)?  (If you support 
hard-float compilation with the soft-float ABI, it would be problematic to 
have different FE_TONEAREST values in the two cases - ARM and RISC-V both 
define all the FE_* macros independently of whether hard or soft float is 
used, because they support that case.)

> diff --git a/sysdeps/arc/math_private.h b/sysdeps/arc/math_private.h

This file should not be needed now.

> diff --git a/sysdeps/arc/nofpu/math-tests-exception.h b/sysdeps/arc/nofpu/math-tests-exception.h

This file does nothing (the name is wrong, the name actually used is 
math-tests-exceptions.h).  And it should not be needed unless you support 
hard-float compilation with the soft-float ABI (and thus define all the 
FE_* names in bits/fenv.h even for soft-float).

> diff --git a/sysdeps/arc/nofpu/math-tests-rounding.h b/sysdeps/arc/nofpu/math-tests-rounding.h

Again, not needed unless hard-float compilation with the soft-float ABI is 
supported and bits/fenv.h has corresponding contents.
  

On Tue, 18 Dec 2018, Joseph Myers wrote:

> On Tue, 18 Dec 2018, Vineet Gupta wrote:
> 
> > +#if defined(__ARC_FPU_SP__) || defined(__ARC_FPU_DP__)
> 
> Missing spaces before '(' (should have such spaces in most cases between 
> an identifier or keyword and '(' - calls to "defined", calls to functions, 
> calls to macros, __attribute__, etc. - except for a few cases of calls to 
> macros such as ElfW where the result is logically used like an 
> identifier).

Or, of course, just omit the parentheses in the "defined" case, which is 
very common for calls to "defined" in glibc.

(Function-like macro definitions are a case where you *can't* have the 
space because the syntax of C requires no space between the name of the 
macro being defined and the '(' before the list of argument names.)
  

On 12/18/18 4:01 PM, Joseph Myers wrote:
> On Tue, 18 Dec 2018, Joseph Myers wrote:
> 
>> On Tue, 18 Dec 2018, Vineet Gupta wrote:
>>
>>> +#if defined(__ARC_FPU_SP__) || defined(__ARC_FPU_DP__)
>> Missing spaces before '(' (should have such spaces in most cases between 
>> an identifier or keyword and '(' - calls to "defined", calls to functions, 
>> calls to macros, __attribute__, etc. - except for a few cases of calls to 
>> macros such as ElfW where the result is logically used like an 
>> identifier).
> Or, of course, just omit the parentheses in the "defined" case, which is 
> very common for calls to "defined" in glibc.
> 
> (Function-like macro definitions are a case where you *can't* have the 
> space because the syntax of C requires no space between the name of the 
> macro being defined and the '(' before the list of argument names.)

Ok, done !
  

On 12/18/18 3:23 PM, Joseph Myers wrote:
> On Tue, 18 Dec 2018, Vineet Gupta wrote:
> 
>> +#if defined(__ARC_FPU_SP__) || defined(__ARC_FPU_DP__)
> 
> Missing spaces before '(' (should have such spaces in most cases between 
> an identifier or keyword and '(' - calls to "defined", calls to functions, 
> calls to macros, __attribute__, etc. - except for a few cases of calls to 
> macros such as ElfW where the result is logically used like an 
> identifier).

OK, I removed the parens in this case (update: removed the guard altogether, see
below).

>> +/* In the soft-float case, only rounding to nearest is supported, with
>> +   no exceptions.  */
> 
> To confirm: hard-float and soft-float are always different ABIs; you don't 
> support hard-float compilation using the soft-float function calling ABI 
> (like is supported for ARM and RISC-V, for example)? 

I'm still ramping up on hard-float, so pardon some of my naivety. It seems the
function calling convention is no different for soft-float vs. hard-float. We have
a single register file (hard FP instructions inherently use an additional
accumulator but that isn't really passed around so doesn't affect calling
convention). Other than that SP values go normally in a reg, DP go in reg pair
just as any 64bit value.

OTOH, the ARC libgcc float emulation code seems likely to be limited in terms of
rounding modes supported etc (the current code is dense math implemented in ARC
assembly (really not my cup of coffee) so I couldn't be sure :-(

At any rate, assuming it did limit the rounding modes etc, does that also lend
into the ABI we are talking about here ? Likely not.


> (If you support 
> hard-float compilation with the soft-float ABI, it would be problematic to 
> have different FE_TONEAREST values in the two cases - ARM and RISC-V both 
> define all the FE_* macros independently of whether hard or soft float is 
> used, because they support that case.)

I'd much rather have them be the same. The fenv.h I started with didn't
distinguish these (well it only had 1 rounding mode: FE_TONEAREST so was bogus at
best). When I revered it up, I added the various modes etc w/o the header guard
and ho behold all the math tests started failing. My knee jerk response was to
segregate them which likely papered over the issue.


>> diff --git a/sysdeps/arc/math_private.h b/sysdeps/arc/math_private.h
> 
> This file should not be needed now.

Ok deleted.


>> diff --git a/sysdeps/arc/nofpu/math-tests-exception.h b/sysdeps/arc/nofpu/math-tests-exception.h
> 
> This file does nothing (the name is wrong, the name actually used is 
> math-tests-exceptions.h).  And it should not be needed unless you support 
> hard-float compilation with the soft-float ABI (and thus define all the 
> FE_* names in bits/fenv.h even for soft-float).

File renamed and retained.

>> diff --git a/sysdeps/arc/nofpu/math-tests-rounding.h b/sysdeps/arc/nofpu/math-tests-rounding.h
> 
> Again, not needed unless hard-float compilation with the soft-float ABI is 
> supported and bits/fenv.h has corresponding contents.

ditto !

Now trying a rebuilt with these changes !
  

On Thu, 20 Dec 2018, Vineet Gupta wrote:

> I'm still ramping up on hard-float, so pardon some of my naivety. It seems the
> function calling convention is no different for soft-float vs. hard-float. We have
> a single register file (hard FP instructions inherently use an additional
> accumulator but that isn't really passed around so doesn't affect calling
> convention). Other than that SP values go normally in a reg, DP go in reg pair
> just as any 64bit value.

If you have only a single register file and the same calling convention - 
and all struct layouts etc. are also the same - then indeed that would be 
a single ABI (meaning that you only need one dynamic linker name for ARC 
rather than two, if you only support one endianness).  (On architectures 
with separate register files, jmp_buf, ucontext etc. might sometimes 
differ between hard and soft float, although often the space is still 
there in the soft-float case, just not used.)

The ARM and RISC-V cases are ones where there are separate hard-float and 
soft-float calling conventions - but *also* support for using hardware 
floating point with the soft-float calling convention.

If you do have a single ABI, that indicates having bits/fenv.h contents 
unconditional (because a soft-float compilation might legitimately end up 
linking with a hard-float libm) - and thus indeed needing the internal 
headers to disable certain math tests for soft-float.  fpu_control.h 
contents would still be conditional, however.