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.
|