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

[Kostya Serebryany]

On Tue, Oct 30, 2012 at 11:24 AM, Chandler Carruth <chandlerc at google.com>wrote:

> 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.
>


In my experience with msan, no-return call is all we need.
But Evgeniy used msan on larger apps than I did, let's see what he says.
If we need any suppressions, no-return call is not a choice.



> > 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121030/ef94dbd2/attachment.html>