Re: [RISC-V] [tech-unprivileged] [RISC-V] [tech-vector-ext] FP Trapped exceptions needed for portability
toggle quoted message Show quoted text
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.
On Fri, Dec 17, 2021 at 3:46 PM Bruce Hoult <bruce@...> wrote: