Changes

[NFC] Make the describeLoadedValue() hook return machine operand objects
Summary: This changes the ParamLoadedValue pair which the
describeLoadedValue() hook returns so that MachineOperand objects are
returned instead of pointers.
When describing call site values we may need to describe operands which 
are not part of the instruction. One such example is zero-materializing 
XORs on x86, which I have implemented support for in a child revision. 
Instead of having to return a pointer to an operand stored somewhere 
outside the instruction, start returning objects directly instead, as 
that simplifies the code.
The MachineOperand class only holds POD members, and on x86-64 it is 32 
bytes large. That combined with copy elision means that the overhead of 
returning a machine operand object from the hook does not become very 
large.
I benchmarked this on a 8-thread i7-8650U machine with 32 GB RAM. The 
benchmark consisted of building a clang 8.0 binary configured with:
  -DCMAKE_BUILD_TYPE=RelWithDebInfo \
 -DLLVM_TARGETS_TO_BUILD=X86 \
 -DLLVM_USE_SANITIZER=Address \
 -DCMAKE_CXX_FLAGS="-Xclang -femit-debug-entry-values -stdlib=libc++"
The average wall clock time increased by 4 seconds, from 62:05 to 62:09,
which is an 0.1% increase.
Reviewers: aprantl, vsk, djtodoro, NikolaPrica
Reviewed By: vsk
Subscribers: hiraditya, ychen, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D67261
llvm-svn: 371332

[DebugInfo][X86] Describe call site values for zero-valued imms
Summary: Add zero-materializing XORs to X86's describeLoadedValue() hook
in order to produce call site values.
I have had to change the defs logic in collectCallSiteParameters() a bit 
to be able to describe the XORs. The XORs implicitly define $eflags, 
which would cause them to never be considered, due to a guard condition 
that I->getNumDefs() is one. I have changed that condition so that we 
now only consider instructions where a forwarded register overlaps with 
the instruction's single explicit define. We still need to collect the
implicit defines of other forwarded registers to remove them from the
work list. I'm not sure how to move towards supporting instructions with
multiple explicit defines, cases where forwarded register are implicitly
defined, and/or cases where an instruction produces values for multiple
forwarded registers. Perhaps the describeLoadedValue() hook should take
a register argument, and we then leave it up to the hook to describe the
loaded value in that register? I have not yet encountered a situation
where that would be necessary though.
Reviewers: aprantl, vsk, djtodoro, NikolaPrica
Reviewed By: vsk
Subscribers: ychen, hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D67225
llvm-svn: 371333

Do not intercept malloc_usable_size on NetBSD
llvm-svn: 371334

Enable leak-detection for NetBSD/amd64 in test/asan
llvm-svn: 371335

[ASan] Only run dlopen-mixed-c-cxx.c with static runtime
This is what the original bug (http://llvm.org/PR39641) and the fix in
https://reviews.llvm.org/D63877 have been about. With the dynamic
runtime the test only passes when the asan library is linked against
libstdc++: In contrast to libc++abi, it does not implement
__cxa_rethrow_primary_exception so the regex matches the line saying
that asan cannot intercept this function. Indeed, there is no message
that the runtime failed to intercept  __cxa_throw.
Differential Revision: https://reviews.llvm.org/D67298
llvm-svn: 371336

Stop marking 5 ASan tests as failing on NetBSD/i386
Unexpected Passing Tests (4):
   AddressSanitizer-i386-netbsd :: TestCases/Posix/coverage-reset.cpp
   AddressSanitizer-i386-netbsd :: TestCases/Posix/coverage.cpp
   AddressSanitizer-i386-netbsd ::
TestCases/Posix/interception-in-shared-lib-test.cpp
   AddressSanitizer-i386-netbsd :: TestCases/suppressions-library.cpp
llvm-svn: 371337