[llvm-dev] [cfe-dev] RFC: Replacing the default CRT allocator on Windows

Neil Henning via llvm-dev llvm-dev at lists.llvm.org
Thu Jul 2 00:58:24 PDT 2020


Not against this for the executables, but I just wanted to 100% check that
it is possible to override malloc/free for clang and not for the
libclang.dll?

I think it's fine to make the built executables use a different allocator,
but it'd be a bigger pain if we force an allocator on users that link
against the LLVM libraries or shared libraries by default.

Cheers,
-Neil.

On Thu, Jul 2, 2020 at 5:54 AM Michael Kruse via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I'd appreciate the speed-up due to the inclusion of an alternative
> malloc and the ease of using it if its source was included in the LLVM
> repository. We already have multiple sources from external projects
> included in the repository (among them gtest, gmock, ConvertUTF,
> google benchmark, ISL, ...) and don't see a reason why it should be
> different for a malloc implementation.
>
> AFAIK replacing malloc is quite common for Windows projects. The
> Windows default implementation (called "low fragmentation heap") has
> different optimization goals.
>
> I'd start with including it in the repository and providing the option
> to enable it, with the possibility to change it to the default after
> some experience has been collected, maybe even with multiple malloc
> implementations.
>
> Michael
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


-- 
Neil Henning
Senior Software Engineer Compiler
unity.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200702/99a160f9/attachment.html>


More information about the llvm-dev mailing list