[llvm-commits] [PATCH] MemorySanitizer instrumentation pass.

[Chandler Carruth]

On Mon, Oct 29, 2012 at 11:28 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>> > > 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?
>> > 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).
>> >
>> I would like to understand why cold function calls aren't sunk (including
>> their spills) out of the flow of the hot path.
>>
>> 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.
>>
>> 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.
>>
>
> I think we can use llvm.trap for now and exit on the first detected bug.

Do you mean a no-return call to the runtime function? I think that's
what we do in ASan now? Ideally, they would be the same.

> This is the current default mode anyway. Evgeniy, right?
> We can later implement the cold calling convention and replace llvm.trap
> with cold calls.
>
>>
>> Also, is there any discussion of the rationale behind fatal errors in ASan
>> and non-fatal here? (similarly for tsan)
>
>
> asan has the best signal vs noise ratio and thus we decided to exit on first
> error. This makes the code smaller/faster.
> tsan does all error reporting inside the run-time library, so the generated
> code is not affected by this choice.
> 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.

I think for simplicity, I'd go with exactly the same behavior as ASan
at first. If we find it doesn't work, we should add the flexibility
then.

>
>
> --kcc
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>