<br><br><div class="gmail_quote">On Tue, Oct 30, 2012 at 11:24 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, Oct 29, 2012 at 11:28 PM, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br>
><br>
>> > > I don't understand any of this. Why aren't we using trap? Why aren't<br>
>> > > 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<br>
>> > scratch registers in the caller, etc - it's way too slow (AFAIR, it's ~20%<br>
>> > slower than ud2 for very cold calls).<br>
>> ><br>
>> I would like to understand why cold function calls aren't sunk (including<br>
>> their spills) out of the flow of the hot path.<br>
>><br>
>> Could this be factored so that there is a switch controlling it, and a<br>
>> specific function for building a "call" to the warning function? I'm not<br>
>> thrilled about names like "WarningFn" referring to things other than a<br>
>> function. I don't expect this inline asm production to be expensive, why not<br>
>> just do this as-needed in a helper method? That might make it easier to gate<br>
>> different behaviors on a flag.<br>
>><br>
>> Eventually, I agree that implementing a dedicated calling convention that,<br>
>> for example, doesn't spill would be really useful to make the IR more clear.<br>
>> Catching and handling ud2 inline asm is really magical.<br>
>><br>
><br>
> I think we can use llvm.trap for now and exit on the first detected bug.<br>
<br>
</div>Do you mean a no-return call to the runtime function? I think that's<br>
what we do in ASan now? Ideally, they would be the same.<br></blockquote><div><br></div><div><br></div><div>In my experience with msan, no-return call is all we need. </div><div>But Evgeniy used msan on larger apps than I did, let's see what he says.</div>
<div>If we need any suppressions, no-return call is not a choice.    </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> This is the current default mode anyway. Evgeniy, right?<br>
> We can later implement the cold calling convention and replace llvm.trap<br>
> with cold calls.<br>
><br>
>><br>
>> Also, is there any discussion of the rationale behind fatal errors in ASan<br>
>> and non-fatal here? (similarly for tsan)<br>
><br>
><br>
> asan has the best signal vs noise ratio and thus we decided to exit on first<br>
> error. This makes the code smaller/faster.<br>
> tsan does all error reporting inside the run-time library, so the generated<br>
> code is not affected by this choice.<br>
> msan is still in development and we are not sure if it will have the same<br>
> signal vs noise ratio as asan. Maybe llvm.trap *is* the best choice.<br>
<br>
</div>I think for simplicity, I'd go with exactly the same behavior as ASan<br>
at first. If we find it doesn't work, we should add the flexibility<br>
then.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> --kcc<br>
><br>
> _______________________________________________<br>
> llvm-commits mailing list<br>
> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
><br>
</div></div></blockquote></div><br>