[PATCH] D97854: [RFC][nsan] A Floating-point numerical sanitizer.

Wed Nov 30 15:54:13 PST 2022

andrew.w.kaylor added a comment.

This looks very interesting. I had a discussion with someone at the recent LLVM Dev Meeting about the possibility of something like this. However, rather than tracking error based on data precision, I am interested in tracking errors introduced by fast-math based optimizations. For instance, someone has a program with has been verified within accuracy requirements, but they want it to run faster so they enable fast-math. Sometimes this works, but other times the fast-math optimizations introduce an unacceptable amount of error. What I'd like is to be able to trace the problem back to which part of the original source was sensitive to this error so that I can disable fast-math locally for just that operation.

Another potential use for this sort of technology relates to an RFC that I just posted (https://reviews.llvm.org/D138867). There I'm trying to introduce a mechanism that allows the compiler to replace builtin math operations (calls to math library functions or equivalent builtins in platforms like SYCL or CUDA) based on a specified accuracy requirement. One of the challenges with this is verifying that the substitute call is really as accurate as it claims. For example, let's say I want to call cosf() and I need 4 ulp accuracy. The standard GNU libm implementation claims 1 ulp accuracy, so it's not necessarily useful as a point of comparison. But if we had a shadow computation that converted the input value to double and called cos() then converted that result back to float, that should give me the correctly rounded result, right? Or I could use a shadow call to one of the various correctly rounded implementations that are becoming available. It would be great to use nsan to verify the results from these alternate library calls.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97854/new/

https://reviews.llvm.org/D97854