similar to: RFC: Replacing the default CRT allocator on Windows

Thanks for the suggestion James, it reduces the commit by about ~900 MB (14,9 GB -> 14 GB). Unfortunately it does not solve the performance problem. The heap is global to the application and thread-safe, so every malloc/free locks it, which evidently doesn’t scale. We could manually create thread-local heaps, but I didn’t want to go there. Ultimately allocated blocks need to share ownership

For release builds, I think this is fine. However for debug builds, the Windows allocator provides a lot of built-in functionality for debugging memory issues that I would be very sad to lose. Therefore, I would request that: 1. This be added as a configuration option to either select the new allocator or the windows allocator 2. The Windows allocator be used by default in debug builds

Asan and the Debug CRT take different approaches, but the problems they cover largely overlap. Both help with detection of errors like buffer overrun, double free, use after free, etc. Asan generally gives you more immediate feedback on those, but you pay a higher price in performance. Debug CRT lets you do some trade off between the performance hit and how soon it detects problems. Asan

I hadn't heard this before. If I use clang with -fsanitize=address to build my program, and then run my program, what difference does it make for the execution of my program whether the compiler itself was instrumented or not? Do you mean that ASAN runtime itself should be instrumented, since your program loads that at runtime? On Tue, Jul 7, 2020 at 2:04 PM Mitch Phillips <mitchp at

Hey list, TL;DR - LLVM 10 is around 7-8% slower than LLVM 9 when compiling the same inputs. So here at Unity our Burst HPC# compiler uses LLVM to provide our users with some very optimal codegen. LLVM is used in two ways: 1. In the Unity editor we JIT compile user code. 2. We also have an AOT mode for when our users are building a full game. Particularly for 1., compile time really matters for

Hi Osman, You can’t enable the static CRT through the command-line. You would need to apply this patch: https://reviews.llvm.org/D55056 (although it doesn’t work with lldb) Alex. ________________________________ De : llvm-dev <llvm-dev-bounces at lists.llvm.org> de la part de Osman Zakir via llvm-dev <llvm-dev at lists.llvm.org> Envoyé : 28 octobre 2019 07:47:43 À : llvm-dev at

Times for lld compiled with LTO: Input File Reading: 1430 ms ( 3.3%) Code Layout: 486 ms ( 1.1%) PDB Emission (Cumulative): 41042 ms ( 94.6%) Add Objects: 33117 ms ( 76.4%) Type Merging: 25861 ms ( 59.6%) Symbol Merging: 7011 ms ( 16.2%) TPI Stream Layout: 996 ms ( 2.3%) Globals Stream Layout:

This could be ICF. There were lots of issues with ICF on ARM64, but they are not inherently ARM64-specific, they just come up there more often. See https://reviews.llvm.org/D56986 which fixes that. Easiest thing is always to profile or add /time to see what's slow. On Wed, Feb 27, 2019 at 6:30 AM Leonardo Santagada <santagada at gmail.com> wrote: > Anyone would know why lld takes

Yes, -Tllvm works. [cid:image002.jpg at 01D4CCF6.C440CFF0] From: Zachary Turner <zturner at google.com> Sent: Monday, February 25, 2019 10:36 AM To: Leonardo Santagada <santagada at gmail.com> Cc: Alexandre Ganea <alexandre.ganea at ubisoft.com>; Reid Kleckner <rnk at google.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Making LLD PDB

Can you please try using Ninja instead? cmake -G Ninja f:/svn/llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_OPTIMIZED_TABLEGEN=true -DLLVM_EXTERNAL_LLD_SOURCE_DIR=f:/svn/lld -DLLVM_TOOL_LLD_BUILD=true -DLLVM_ENABLE_LLD=true -DCMAKE_C_COMPILER="C:/Program Files/LLVM/bin/clang-cl.exe" -DCMAKE_CXX_COMPILER="C:/Program Files/LLVM/bin/clang-cl.exe" -DCMAKE_LINKER="C:/Program

Sadly the patch on https://reviews.llvm.org/D55585 didn't apply on my clone of llvm at all :( It will take me quite some time to test this out. On Mon, Feb 25, 2019 at 5:08 PM Alexandre Ganea <alexandre.ganea at ubisoft.com> wrote: > > For enabling large memory pages, see this link: https://support.sisoftware.co.uk/knowledgebase.php?article=52 > > Meow hash isn't in the

I think its a huge bug that it doesn't raise any errors or warnings about it. But I will open a ticket on cmake, they should be using clang-cl.exe and lld-link.exe if T="llvm" probably set host to 64 bit as well. On Mon, Feb 25, 2019 at 3:34 PM Zachary Turner <zturner at google.com> wrote: > > I don’t think changing the compiler or linker is supported with the vs

As for multithreaded ghashes: Even if the hashtable stores 32-bit indices to SeenHashes, you would still need to compare the ghashes for collisions: https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/ADT/DenseMap.h#L627 Finding the 32-bit index in the hashtable doesn’t necessarily mean it’s the right one. The following table shows the collision distribution when inserting (type)

That's good news. For having debug info, you could try adding /Z7 on the cmake cmd-line, such as -DCMAKE_CXX_FLAGS="/Z7". Or use the 'RelWithDebInfo' target instead of 'Release' and add -DCMAKE_CXX_FLAGS="/Ob2" (because that target uses /Ob1 as a default). Can you please send a patch on Phabricator if you fix the LLVM_ENABLE_PDB issue with Clang? The goal

How do you compile LLD? There's a big difference between when using MSVC vs Clang. The parallel ghash patch I was mentioning is almost 2x as fast when using Clang 7.0+ vs. MSVC 15.9+, I don't know exactly why. I also suggest you use the Release target. You should also grab this patch: https://reviews.llvm.org/D55056 - I had to revert it because it was causing issues with LLDB. But it

Hi, I’d just like to interject to say that building within Visual Studio isn’t really that bad. Running the lit tests is a bit painful because the LLVM build tools that are integrated with the build system don’t play nice with msbuild. Particularly, I’ve never been able to actually cancel an invocation of lit or tablegen via visual studio. That said, there is a huge upside to building with

Hello, I sometime forget to set the "Repository" when uploading a patch on Phabricator, and that prevents from adding llvm-commits as a subscriber. [cid:image001.png at 01D61A45.E388B060] Would it make sense to set 'LLVM Github Monorepo' as a default? Or subscribe 'llvm-commits' automatically when creating a patch? Thanks! Alex. -------------- next part --------------

Leonardo, to answer to your questions, yes to all of them  You can take a look at this prototype/proposal: https://reviews.llvm.org/D55585 Overall, computing ghashes in parallel at link-time and merging Types with them is less costly that the current approach to merging. The 35sec you’re seeing for merging should go down to about 15sec. The patch doesn’t parallelize (yet) the Type merging

Hello, Is there a way for Phabricator to retain the patches as originally uploaded? When using the "Download Raw Diff" button, it seems Phabricator reformats the patch, loosing the parent commit along the way, so often patches don't apply. The following works, because I've got the latest checkout on master, and the patch was rebased recently: F:\llvm-project>curl

On Wed, Feb 27, 2019 at 3:17 PM Leonardo Santagada <santagada at gmail.com> wrote: > > Also we are investigating why we have 420 million types being linked while > it appears that 95-99 % of them are not being used. De anyone know if pch > can help here? My feeling is not much as template instantiation still > generates a ton of weak symbols on the pch users, but I might be