<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> > I don't understand any of this. Why aren't we using trap? Why aren't we following the pattern of ASan? What is the goal of UseTrap?<br>
> Unlike ASan, we want MSan reports to be non-fatal. Normal call spills scratch registers in the caller, etc - it's way too slow (AFAIR, it's ~20% slower than ud2 for very cold calls).<br>
><br>
</div>I would like to understand why cold function calls aren't sunk (including their spills) out of the flow of the hot path.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 Could this be factored so that there is a switch controlling it, and a specific function for building a "call" to the warning function? I'm not thrilled about names like "WarningFn" referring to things other than a function. I don't expect this inline asm production to be expensive, why not just do this as-needed in a helper method? That might make it easier to gate different behaviors on a flag.<br>

<br>
Eventually, I agree that implementing a dedicated calling convention that, for example, doesn't spill would be really useful to make the IR more clear. Catching and handling ud2 inline asm is really magical.<br>
<br></blockquote><div><br></div><div><div class="gmail_quote"><div>I think we can use llvm.trap for now and exit on the first detected bug. This is the current default mode anyway. Evgeniy, right?</div></div><div class="gmail_quote">
We can later implement the cold calling convention and replace llvm.trap with cold calls.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, is there any discussion of the rationale behind fatal errors in ASan and non-fatal here? (similarly for tsan)<br></blockquote><div><br></div><div>asan has the best signal vs noise ratio and thus we decided to exit on first error. This makes the code smaller/faster.</div>
<div>tsan does all error reporting inside the run-time library, so the generated code is not affected by this choice. </div><div>msan is still in development and we are not sure if it will have the same signal vs noise ratio as asan. Maybe llvm.trap *is* the best choice. </div>
<div><br></div><div><br></div><div>--kcc </div></div>