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

[Andy Kaylor via Phabricator via cfe-commits]

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

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

This looks very interesting and I wish that I can help as well (but I'll likely 
spend very little time in December due to holidays:) ). Hmm, I can't find it in 
an email archive. Perhaps there hasn't been a discussion so people are unaware 
of this work...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97854

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Clement Courbet via Phabricator via cfe-commits]

courbet added a subscriber: titeup.
courbet added a comment.

In D97854#3944804 , @olologin wrote:

> @courbet 
> Hi, sorry for pinging you.
> Is this review stalled? Is there a reason for this? Judging by paper this 
> sanitizer looks promising. I was recently planning to try out NSAN on huge 
> codebase but I only found this review, so I wonder if I should try to build 
> clang with your patch myself and try it.
>
> Maybe I could help with something if you don't have time for completing this 
> review, but I doubt my knowledge of LLVM codebase is good enough for serious 
> tasks :)

The interest for this in the LLVM community did not seem overwhelming, so I did 
not pursue this.

There was some work out-of-tree by the interflop 
 (in particular, @titeup), e.g 
https://github.com/Thukisdo/NSan-interflop-runtime, I'm not sure if they are 
still working on it.

If you want to try to get this submitted, feel free to take over !


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97854

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Ibraim Ganiev via Phabricator via cfe-commits]

olologin added a comment.

@courbet 
Hi, sorry for pinging you.
Is this review stalled? Judging by paper this sanitizer looks promising. I was 
recently planning to try out NSAN on huge codebase.
Is there anything wrong with this review? Just curious. Maybe I could help with 
something but I doubt I know LLVM codebase good enough :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97854

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Clement Courbet via Phabricator via cfe-commits]

courbet added a comment.

In D97854#2617097 , @scanon wrote:

> Is there a mechanism to instruct the sanitizer to ignore a specific 
> expression or function? From a cursory reading, I am mildly concerned about a 
> deluge of false positives from primitives that compute exact (or approximate) 
> residuals; these are acting to eliminate or precisely control floating-point 
> errors, but tend to show up as "unstable" in a naive analysis that isn't 
> aware of them.

Yes: like all sanitizers, what happens behind the scenes is that the frontend 
(`clang`) sets an annotation on each function in the program. It can be 
disabled for a specific function with the no_sanitize 
 attribute.

If `nsan` is disabled for a specific function, any return value will be 
re-extended again to shadow precision, and the computations will resume from 
here. This is equivalent to  assuming that the function, its parameters, and 
any memory reads were correct.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97854

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Steve Canon via Phabricator via cfe-commits]

scanon added a comment.

Is there a mechanism to instruct the sanitizer to ignore a specific expression 
or function? From a cursory reading, I am mildly concerned about a deluge of 
false positives from primitives that compute exact (or approximate) residuals; 
these are acting to eliminate or precisely control floating-point errors, but 
tend to show up as "unstable" in a naive analysis that isn't aware of them.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97854

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Clement Courbet via Phabricator via cfe-commits]

courbet added a comment.

When bootstrapping LLVM with nsan, there are only a few issues.

Several of them stem from using `double` to measure elapsed time in seconds: We 
measure start time, end time, and subtract them. The resulting error depends on 
the arbitrary magnitude of the time since epoch, so as time passes the error 
will increase. This is especially visible when we measure short intervals of 
time (e.g. a few microseconds, which are small compared to the time since 
epoch).

For example one test has more than 2% error:

  WARNING: NumericalStabilitySanitizer: inconsistent shadow results while 
checking store to address 0x4b87860
  double   precision  (native): dec: 0.0858306884765625  hex: 
0x1.2000p-17
  __float128   precision  (shadow): dec: 0.08806000  hex: 
0x9.3bd7b64e9fe4fc00p-20
  shadow truncated to double  : dec: 0.08806000  hex: 
0x1.277af6c9d3fca000p-17
  Relative error: 2.53158247040370201937% (2^47 epsilons)
  Absolute error: 0x1.debdb274ff27e000p-23
  (131595325226954 ULPs == 14.1 digits == 46.9 bits)
  #0 0x119db71 in llvm::TimeRecord::operator-=(llvm::TimeRecord const&) 
[...]/llvm/llvm-project/llvm/include/llvm/Support/Timer.h:63:14
  #1 0x119db71 in llvm::Timer::stopTimer() 
[...]/llvm/llvm-project/llvm/lib/Support/Timer.cpp:176:8
  #2 0x108b1d2 in llvm::TimePassesHandler::stopTimer(llvm::StringRef) 
[...]/llvm/llvm-project/llvm/lib/IR/PassTimingInfo.cpp:248:14
  #3 0x108b1d2 in llvm::TimePassesHandler::runAfterPass(llvm::StringRef) 
[...]/llvm/llvm-project/llvm/lib/IR/PassTimingInfo.cpp:267:3
  #4 0x108e159 in 
llvm::TimePassesHandler::registerCallbacks(llvm::PassInstrumentationCallbacks&)::$_2::operator()(llvm::StringRef,
 llvm::Any, llvm::PreservedAnalyses const&) const 
[...]/llvm/llvm-project/llvm/lib/IR/PassTimingInfo.cpp:281:15
  #5 0x108e159 in void llvm::detail::UniqueFunctionBase::CallImpl(void*,
 llvm::StringRef, llvm::Any&, llvm::PreservedAnalyses const&) 
[...]/llvm/llvm-project/llvm/include/llvm/ADT/FunctionExtras.h:204:12
  #6 0xa4f826 in llvm::unique_function::operator()(llvm::StringRef, llvm::Any, 
llvm::PreservedAnalyses const&) 
[...]/llvm/llvm-project/llvm/include/llvm/ADT/FunctionExtras.h:366:12
  #7 0xa4f826 in void llvm::PassInstrumentation::runAfterPass((anonymous namespace)::MyPass2 const&, 
llvm::Module const&, llvm::PreservedAnalyses const&) const 
[...]/llvm/llvm-project/llvm/include/llvm/IR/PassInstrumentation.h:227:9
  #8 0xa4f826 in (anonymous 
namespace)::TimePassesTest_CustomOut_Test::TestBody() 
[...]/llvm/llvm-project/llvm/unittests/IR/TimePassesTest.cpp:137:6
  ...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97854

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits