RetroSearch Browse

Thu Jul 2 00:58:24 PDT 2020 · https://lists.llvm.org/pipermail/llvm-dev/2020-July/143022.html

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>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://lists.llvm.org/pipermail/llvm-dev/2020-July/143022.html below:

Replacing the default CRT allocator on Windows