similar to: ThinLTO caching & compression

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

Hello, I was wondering how folks were feeling about replacing the default Windows CRT allocator in Clang, LLD and other LLVM tools possibly. The CRT heap allocator on Windows doesn't scale well on large core count machines. Any multi-threaded workload in LLVM that allocates often is impacted by this. As a result, link times with ThinLTO are extremely slow on Windows. We're observing

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

where should the file build_llvm_package.bat be placed and how should the build_llvm_package.bat be called? or is there a another way to do a two stage build of the llvm project on windows starting with using visual studio 2017 community. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Charles, On Tue, Jul 11, 2017 at 12:27 PM, Davide Italiano <davide at freebsd.org> wrote: >> I'm working on adding interprocedural FunctionAttrs optimization >> (http://llvm-cs.pcc.me.uk/lib/Transforms/IPO/FunctionAttrs.cpp) to ThinLTO >> so it does something similar to what LTO is doing >> (https://bugs.llvm.org/show_bug.cgi?id=33648). I've hit a problem

Hey all, I'm working on adding interprocedural FunctionAttrs optimization ( http://llvm-cs.pcc.me.uk/lib/Transforms/IPO/FunctionAttrs.cpp) to ThinLTO so it does something similar to what LTO is doing ( https://bugs.llvm.org/show_bug.cgi?id=33648). I've hit a problem with how the FunctionAttrs optimization expects linkage types. In ThinLTO since the linkage type is set to External or

Hi, I wanted to get the linked result in LLVM bitcode format. With LTO, this can be done by -flto -Wl,-plugin-opt,emit-llvm. Instead of generating native executables, it outputs a file with bitcode format. Does this still work with -flto=thin? -flto=thin -Wl,-plugin-opt,emit-llvm outputs a bitcode file, but its file size is too small, and does not contain all contents. What is the correct way

Hi: &nbsp; &nbsp; I want to learn&nbsp; how LTO and thinLTO work? But I'm confused how lld invoked either library. How can I find it in lld. Should i be familiar with lld source code? And i also think if there is some easy test case and with step-by- step debugging or some log messages can help me learn this? Is there some method can do stuff like this? &nbsp; Thank you very

Hello, My impression on *thinLTO* when I first heard of it, (EuroLLVM2015) was about achieving Cross Module Optimization (CMO) at the IR level. Having parallel front-end compilation & initial optimization first, a thin-link of individual input units, more optimization by calling opt again on the combined IR, and finally the target codegen using llc. A transformation similar to the

I'm trying to run distributed ThinLTO without thin archives. When I do, I get an error in the optimizer when clang tries to open a nonexistent file: clang++ -flto=thin -Xclang -fno-lto-unit -O3 -c main.cpp -o main.o clang++ -flto=thin -Xclang -fno-lto-unit -O3 -c lib/lib.cpp -o lib/lib.o clang++ -flto=thin -Xclang -fno-lto-unit -O3 -c src/lib.cpp -o src/lib.o llvm-ar -format gnu qcs lib.a

Our ThinLTO testing was inoperative for a while, and now that it's running again, we're seeing the linker step reporting "Expected a single module." Note that our linker is using the C API to read bitcode. It looks like the ThinLTO writer now emits two modules, but AFAICT most of the APIs in BitcodeReader.cpp expect to see only one. Is this just an oversight in supporting

Hi, I’m working on setting up ThinLTO+CFI for a C application which uses a lot of function pointers. While functionally it appears stable, it’s performance is significantly degraded, to the tune of double digit percentage points compared to regular LTO+CFI. Looking into possible causes I see that under ThinLTO+CFI iCall type checks almost always generate jump table entries for indirect calls,

Hi, I'm working on enabling thinLTO for our custom backend on LLVM-8 with lld to get code size benefits from dead symbol elimination. The code in LTO::run() of LTO.cpp confuses me that, even though thinLTO is specified, runRegularLTO() will be run first and its return value determines whether runThinLTO() will be executed. My question is if it's clearly known that thinLTO is used, is it

On Wed, Jul 12, 2017 at 10:19 AM, Teresa Johnson <tejohnson at google.com> wrote: > Hi Christu, > > Thanks for the note! > > On Wed, Jul 12, 2017 at 9:56 AM, Christudasan D via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hello, >> >> >> >> My impression on *thinLTO* when I first heard of it, (EuroLLVM2015) was >> about

On Mon, Oct 3, 2016 at 4:27 PM, Teresa Johnson <tejohnson at google.com> wrote: > > > On Mon, Oct 3, 2016 at 6:53 AM, Johan Engelen via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> I am trying to add ThinLTO to the LDC compiler. It seems to work well >> on Mac (XCode 8) and Ubuntu (ld.gold + LLVMgold plugin). >> However, I am

On Thu, May 4, 2017 at 7:22 AM, Rafael Avila de Espindola via llvm-dev < llvm-dev at lists.llvm.org> wrote: > David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > So Dehao and I have been dealing with some of the nitty gritty details of > > debug info with ThinLTO, specifically with Fission(Split DWARF). > > > > This applies to LTO as

Hey All, My name is Charles, and I'm interested in working on LLVM for GSOC. I watched the 2016 LLVM conference ThinLTO talk and found it super interesting. I'd like to work on it for GSOC. Since I'm currently working on my proposal, I talked\ with Mehdi on IRC to learn more about the project and find what kind of contribution would be useful. He mentioned that the big pieces of work

Thanks! Question about the final link step: Do I provide all the object files to the link step, i.e. something like: clang++ -o thinlto main-native.o lib/lib-native.o src/lib-native.o Do I need to provide --start-lib markers on that final link step as well? Tanoy On Tue, Jun 18, 2019 at 10:37 AM Teresa Johnson <tejohnson at google.com> wrote: > Hi Tanoy, > > You can't use

Hi all, I am trying to figure out the best way to deal with non-default TargetMachine options when using ThinLTO with the LLVMgold.so plugin. (I'm adding support for ThinLTO to the LDC D compiler) Things like the target triple, target CPU and target CPU features, some floating point options like unsafe-fp-math, etc., those are (or can be made) explicit in the IR. Is that the way to go? We