Support Visual Studio heap profiler in MSVC targets

[jdm]

Cland and MSVC support adding special debug info that can be recognized by the MSVC debugging tools for performing heap profiling. Right now all of the allocations from Rust code are put into an "Unresolved allocations" bucket with no stack frames attached to them, which makes them quite useless. Since LLVM 9 the backend supports generating the appropriate codeview information if the frontend creates the right metadata, so it would be great to allow rustc to generate that metadata.

Based on:

• https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html#windows-support
• https://clang.llvm.org/docs/AttributeReference.html#allocator
• https://bugs.llvm.org/show_bug.cgi?id=38491
• https://reviews.llvm.org/rL368230

Clang frontend work:

• https://github.com/llvm-mirror/clang/blob/e3b053c27cfd74468e946437526d061c7d88bd27/lib/Sema/SemaDeclAttr.cpp#L6395-L6407
• https://github.com/llvm-mirror/clang/blob/8b10d16729147455fc92b35d180968be9792b880/lib/CodeGen/CGCall.cpp#L4402-L4405
• https://github.com/llvm-mirror/clang/blob/05441b0db7bf23d206dfc865b5c5bde17da1dab0/lib/CodeGen/CGExprScalar.cpp#L2029-L2033
• https://github.com/llvm-mirror/clang/blob/14947e8df1c27d3babf2c01b53c0c2bf2bfb9bd1/lib/CodeGen/CGDebugInfo.cpp#L2050-L2062

We might be able to tie this into the existing GlobalAllocator support. This work may need to wait until #67759 has merged, however.

[jdm]

Given #68030, it should be possible to work on this now.

[jdm]

Important points for clang's implementation:

• need a known set of allocator functions
• need a way to tag callsites of the allocator functions
• need to notice when the type returned by an allocator is cast to a different pointer type and update the tag
• set the "heapallocsite" metadata on the LLVM call instruction to a MDNode that corresponds to the pointer type of the allocation

[jdm]

https://github.com/jdm/rust/tree/heap-profiler is a branch that causes heapallocsite debug metadata to be added to LLVM call instructions for heap allocator functions. I haven't tested the effect on Windows yet, but the IR output is at least different now.

Note to self: write some simple C and look at the LLVM IR for the presence of heapallocsite to compare.

[jdm]

I had a chance to test the branch. I created a cargo library that generated a cdylib, exported a C API from it that has methods for boxing and freeing Rust structures, and pushes values into vectors and creates String values out of C strings. I then created a VS console project that links with this DLL and invokes the C API, while also including some C++ std::string and dynamically allocated arrays.

Using the latest MSVC nightly, enabling heap profiling showed entries for char[] and int[] for the C++ allocations as expected. If I disabled the "Hide unresolved allocations", I could see the Rust allocations bucketed with many other unrelated allocations, since fundamentally liballoc ends up calling the win32 allocation APIs that the heap profiler understands.

With my heap-profiler branch and the "Hide unresolved allocations" option re-enabled, the Rust allocations are now bucketed under unsigned char *[] and are no longer classified as unresolved. This is clearly an improvement, since you no longer have to wade through lots of unrelated win32-internal allocation stacks, but I'm hoping that including higher-level allocation gateways like exchange_malloc will allow us to bucket the resulting allocations in more granular ways.