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

Kostya Serebryany kcc at google.com
Mon Oct 29 23:29:21 PDT 2012

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



More information about the llvm-commits mailing list