1. Tech-Vector-Ext
  2. Topics

[RISC-V] [tech-unprivileged] [RISC-V] [tech-vector-ext] FP Trapped exceptions needed for portability

Krste Asanovic
 


On Dec 17, 2021, at 11:48 AM, andrew@... wrote:

Defining a standard extension that provides precise traps on FP exceptions seems like a reasonable thing to do, if only to facilitate the use case you mention in a standard way. The strategy would presumably be to add another five bits to the fcsr that indicate which exceptions will raise traps.

Yes, this would be the obvious path to take.

Some use cases, including maybe this one, might prefer FP traps to be horizontal into user mode.

But I’ll also briefly remark that not requiring traps on FP exceptions has been a godsend for implementing high-performance in-order cores, where data-dependent traps would preclude early retirement and deferred execution of these instructions. So there’s good reason never to make such an extension mandatory, even in the RVA profiles.

There is the old MIPS FPU pipeline trick of conservative early check of exponent ranges to determine trap is impossible to reduce impact in this case.

But FP trap handling is too non-standard/heavyweight/buggy to get widespread use in portable code (along with other corners of IEEE FP spec), so agree it doesn’t seem to be on path to RVA mandate.

Krste



On Fri, Dec 17, 2021 at 11:31 AM Ken Dockser <kad@...> wrote:
While I understand that it had been decided long ago (relatively speaking) that RISC-V would not support trapping on floating-point exceptions, I am wondering if we need to revisit this.

I have heard that ARM's rationale for adding floating-point exception trap capabilities in ARMv7.8 was not because of an inherent need for new code, but for enabling the efficient porting of X86 code to ARM.

Does anyone out there have any experience with porting X86 code to RISC-V? Has the lack of trapped FP exceptions hindered such porting?
Likewise, is there an interest in proposing a TG to create an extension that adds FP trap capabilities to Scalar and Vector FP.

Thanks,
Ken 
Earl Killian
 

The question I have is whether having this in scalar only would be sufficient? If porting an application were to need exception traps, it seems plausible to disable compiler vectorization.

The MIPS patent should have expired by now, so it would solve the problem (except for inexact) on a simple in-order core. Does anyone know if x86 code uses inexact traps?

On Dec 17, 2021, at 12:02, Krste Asanovic <krste@...> wrote:


On Dec 17, 2021, at 11:48 AM, andrew@... wrote:

Defining a standard extension that provides precise traps on FP exceptions seems like a reasonable thing to do, if only to facilitate the use case you mention in a standard way. The strategy would presumably be to add another five bits to the fcsr that indicate which exceptions will raise traps.

Yes, this would be the obvious path to take.

Some use cases, including maybe this one, might prefer FP traps to be horizontal into user mode.

But I’ll also briefly remark that not requiring traps on FP exceptions has been a godsend for implementing high-performance in-order cores, where data-dependent traps would preclude early retirement and deferred execution of these instructions. So there’s good reason never to make such an extension mandatory, even in the RVA profiles.

There is the old MIPS FPU pipeline trick of conservative early check of exponent ranges to determine trap is impossible to reduce impact in this case.

But FP trap handling is too non-standard/heavyweight/buggy to get widespread use in portable code (along with other corners of IEEE FP spec), so agree it doesn’t seem to be on path to RVA mandate.

Krste



On Fri, Dec 17, 2021 at 11:31 AM Ken Dockser <kad@...> wrote:
While I understand that it had been decided long ago (relatively speaking) that RISC-V would not support trapping on floating-point exceptions, I am wondering if we need to revisit this.

I have heard that ARM's rationale for adding floating-point exception trap capabilities in ARMv7.8 was not because of an inherent need for new code, but for enabling the efficient porting of X86 code to ARM.

Does anyone out there have any experience with porting X86 code to RISC-V? Has the lack of trapped FP exceptions hindered such porting?
Likewise, is there an interest in proposing a TG to create an extension that adds FP trap capabilities to Scalar and Vector FP.

Thanks,
Ken 
Bruce Hoult
 

On Sat, Dec 18, 2021 at 9:09 AM Earl Killian <earl.killian@...> wrote:
The question I have is whether having this in scalar only would be sufficient? If porting an application were to need exception traps, it seems plausible to disable compiler vectorization.

The MIPS patent should have expired by now, so it would solve the problem (except for inexact) on a simple in-order core. Does anyone know if x86 code uses inexact traps?

What's the use-case for trapping on inexact (or even caring about it) in FP? Using doubles as 53 bit integers? I did that myself in accounting software back in the 80s and 90s, but it's a bit pointless on a 64 bit machine.
Zalman Stern
 

I’d suggest identifying important use cases for this. I’d also be looking at software techniques where the compiler inserts checks to provide the necessary support for the use cases first.

Probably the number one use case is a software emulator for x86 binaries on RISC V. (Because one has to provide the exact x86 behavior regardless of whether it is a strong requirement for significant applications.) This alone could have driven things for ARM. The way to investigate would be to look at how Apple’s emulator works.

Glancing at the large corpus of code one can search at Google, yeah, there's enough stuff claiming a SIGFPE is going to happen in certain circumstances that floating point exceptions can't be written off. But most of it looks like stuff that would far better be handled by having the compiler check a hardware provided flag and raise the exception rather than having hardware do everything. (It is mostly stuff that is providing some fairly widely used, non-HPC, mathematical functionality and trying to ensure a program crashes when numerical invariants are violated.)

My first thought was to ask why one would want this at all as I've done a fair bit of signal-processing/HPC-ish work in shipping applications and floating-point exceptions are only ever used as a debugging tool. Generally most of my interaction with the feature has been fixing performance and correctness issues when floating-point exceptions inadvertently get enabled.

-Z-

-Z-

On Fri, Dec 17, 2021 at 3:46 PM Bruce Hoult <bruce@...> wrote:
On Sat, Dec 18, 2021 at 9:09 AM Earl Killian <earl.killian@...> wrote:
The question I have is whether having this in scalar only would be sufficient? If porting an application were to need exception traps, it seems plausible to disable compiler vectorization.

The MIPS patent should have expired by now, so it would solve the problem (except for inexact) on a simple in-order core. Does anyone know if x86 code uses inexact traps?

What's the use-case for trapping on inexact (or even caring about it) in FP? Using doubles as 53 bit integers? I did that myself in accounting software back in the 80s and 90s, but it's a bit pointless on a 64 bit machine.
ghost
 

I’d suggest identifying important use cases for this. I’d also be looking at
software techniques where the compiler inserts checks to provide the
necessary support for the use cases first.
Along with this, I'd suggest considering an extension that consists of just
one instruction: trap if (FP flags & mask in instruction) is non-zero. I'm
not a hardware designer, but it seems to me that this would allow
floating-point computation to run at full speed until a point selected by
the programmer or compiler where a precise trap was needed, and the more
instructions the compiler can place between the FP computation and the
conditional trap, the less likely a pipeline stall.

--

L Peter Deutsch <ghost@...> :: Aladdin Enterprises :: Healdsburg, CA

Was your vote really counted? http://www.verifiedvoting.org
Krste Asanovic
 

I'll note that ARM appears to detect tininess before rounding, while
x86 does so after rounding.

Also, current ARM compilers don't support exception trapping on
AArch64.

https://developer.arm.com/documentation/dui0808/a/floating-point-support/exception-types-recognized-by-the-arm-floating-point-environment

These decisions would not seem to match an intent by ARM to emulate
x86 FP behavior to ease porting.

Krste

On Fri, 17 Dec 2021 16:56:58 -0800, Zalman Stern <zalman@...> said:
| I’d suggest identifying important use cases for this. I’d also be looking at software techniques where the compiler inserts checks to provide the necessary support for the
| use cases first.

| Probably the number one use case is a software emulator for x86 binaries on RISC V. (Because one has to provide the exact x86 behavior regardless of whether it is a strong
| requirement for significant applications.) This alone could have driven things for ARM. The way to investigate would be to look at how Apple’s emulator works.

| Glancing at the large corpus of code one can search at Google, yeah, there's enough stuff claiming a SIGFPE is going to happen in certain circumstances that floating point
| exceptions can't be written off. But most of it looks like stuff that would far better be handled by having the compiler check a hardware provided flag and raise the
| exception rather than having hardware do everything. (It is mostly stuff that is providing some fairly widely used, non-HPC, mathematical functionality and trying to ensure
| a program crashes when numerical invariants are violated.)

| My first thought was to ask why one would want this at all as I've done a fair bit of signal-processing/HPC-ish work in shipping applications and floating-point exceptions
| are only ever used as a debugging tool. Generally most of my interaction with the feature has been fixing performance and correctness issues when floating-point exceptions
| inadvertently get enabled.

| -Z-

| -Z-

| On Fri, Dec 17, 2021 at 3:46 PM Bruce Hoult <bruce@...> wrote:

| On Sat, Dec 18, 2021 at 9:09 AM Earl Killian <earl.killian@...> wrote:

| The question I have is whether having this in scalar only would be sufficient? If porting an application were to need exception traps, it seems plausible to disable
| compiler vectorization.

| The MIPS patent should have expired by now, so it would solve the problem (except for inexact) on a simple in-order core. Does anyone know if x86 code uses inexact
| traps?

| What's the use-case for trapping on inexact (or even caring about it) in FP? Using doubles as 53 bit integers? I did that myself in accounting software back in the 80s
| and 90s, but it's a bit pointless on a 64 bit machine.
|
Allen Baum
 

IF the Trap-on-masked-fflags op isn't executed often, then a 4 instruction sequence 
(CSRRD FFLAGS, ANDI, BNE, .+4, ECALL) would do that, so there is a workaround.
IF that has a performance impact, then it argues that you may need actual trapping behavior.


On Fri, Dec 17, 2021 at 5:05 PM ghost <ghost@...> wrote:
> I’d suggest identifying important use cases for this. I’d also be looking at
> software techniques where the compiler inserts checks to provide the
> necessary support for the use cases first.

Along with this, I'd suggest considering an extension that consists of just
one instruction: trap if (FP flags & mask in instruction) is non-zero.  I'm
not a hardware designer, but it seems to me that this would allow
floating-point computation to run at full speed until a point selected by
the programmer or compiler where a precise trap was needed, and the more
instructions the compiler can place between the FP computation and the
conditional trap, the less likely a pipeline stall.

--

L Peter Deutsch <ghost@...> :: Aladdin Enterprises :: Healdsburg, CA

         Was your vote really counted?  http://www.verifiedvoting.org

1 - 7 of 7