search for: lto'd

A compiler built with LTO / PGO can significantly improve build times. Locally I see ~10% reduction in compilation times of Debug or Release versions of clang/llvm using an LTO'd clang compiler. This is not really news of course (e.g. recently also reconfirmed in https://linuxplumbersconf.org/event/7/contributions/802/)...

...es me a little for linkonce -- there's a minor change to > semantics if the importing module would have linked against a > *different* definition of the same symbol -- but I'm not really > sure it matters much. > > This should not be an issue in practice as it exists non thinLTO compilations too. For instance changing the optimization level of one module can lead to different inline decisions and different copy of the comdat function to be picked up in the end. > > > > I wonder whether a prefix would be better? > > All the promotion/renaming scares me....

...le for linkonce -- there's a minor change to > semantics if the importing module would have linked against a > *different* definition of the same symbol -- but I'm not really > sure it matters much. > > > > This should not be an issue in practice as it exists non thinLTO compilations too. For instance changing the optimization level of one module can lead to different inline decisions and different copy of the comdat function to be picked up in the end. > Good point. > > > > > I wonder whether a prefix would be better? > > All the pro...

...; to be at least twice as fast with -O3 than with -O0. > I also noticed that you use LLC in the final step. An alternative that > works well for me is to use the [1]gold linker plugin. This way, you > can link bitcode files directly into the program by using > clang -flto $(LDFLAGS) <bitcode files> -o <output file> $(LDLIBS) > If your bitcode files have the extension .o, clang will only run LTO > optimizations, code generation, and linking. If they have the extension > .bc, it will run a full set of compilation passes (in which case you...

...them up are not finalized yet, but it may require LLVM support as well. If developing TM support from scratch, I would not put it in the frontend because: 1) Performance. Doing TM instrumentation after running other standard optimizations is worthwhile. Inlining, constant propagation, ... and LTO in general can all give you less loads and stores in txns (which either have a decent overhead for software TM libraries or can count towards hardware TM (HTM) capacity limits). You can potentially do better alias and dependency analysis after other optimizations in IR. 2) The TM support is no...

...number I referred to is a multi-stage clang build. That > means we build a host-capable compiler, then build the actual compiler we > want to ship. > * I’m at Apple, so points 1 and 2 are already covered (we only use clang, > and ld64 is a fast linker). > * Our system compiler is PGO+LTO’d, but our stage1 isn’t. Stage1 isn’t > because the performance improvement of PGO+LTO is less than the time it > takes to build, and stage1 is basically a throwaway. > * We are using Ninja and CMake, but this configuration isn’t really > significantly faster than autoconf/make, and act...

...6, at 4:22 PM, Sedat Dilek <sedat.dilek at gmail.com> wrote: > > I got some more inspirations on how to speedup my build and integrated > the URLs into my scripts (attached). > > For example to use GOLD as linker or to use '-O3' OptLevel maybe in > combination with LTO and PGO (using '-O3 -flto -fprofile-use'). LTO *will* slow down dramatically the build. -- Mehdi > > Let's see when the v3.8.0 FINAL is released. > > - Sedat - > > On 3/2/16, Fabio Pagani <pagabuc at gmail.com> wrote: >> Hey Chris, >> >&g...

...it may > require LLVM support as well. > > If developing TM support from scratch, I would not put it in the frontend > because: > > 1) Performance. Doing TM instrumentation after running other standard > optimizations is worthwhile. Inlining, constant propagation, ... and LTO in > general can all give you less loads and stores in txns (which either have a > decent overhead for software TM libraries or can count towards hardware TM > (HTM) capacity limits). You can potentially do better alias and dependency > analysis after other optimizations in IR. >...

Thanks for the comments! Responses below. Teresa On Tue, Jul 21, 2015 at 1:06 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2015-Jul-14, at 13:33, Teresa Johnson <tejohnson at google.com> wrote: > > > > As mentioned in the Updated ThinLTO RFC ( > http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/086211.html), I am > sending the symbol linkage and renaming required by ThinLTO as a separate > RFC. It is included below. I've also attached the doc in pdf form, since > the formatting (especially for the table at the en...

For faster builds and rebuilds you should definitely read: https://blogs.s-osg.org/an-introduction-to-accelerating-your-build-with-clang/ https://blogs.s-osg.org/a-conclusion-to-accelerating-your-build-with-clang/ Hope this helps! On Tue, Mar 1, 2016 at 9:17 PM, ChrisBieneman via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > > On Mar 1, 2016, at 10:01 AM, Mehdi Amini

Yes, that’s right. Some LLVM terminology though: The blocks you mention, are called the “exiting blocks” of the loop, and the blocks outside the loop (that are the targets of these exiting blocks) are called the exit blocks. getExitingBlocks in LoopInfoImpl.h is the code you’re interested in. By definition: one of the successor’s of the exiting block is an exit block, and it should have another

Hi Torvald, > I would like to know whether the community is interested in getting support > for Transactional Memory (TM) merged in upstream LLVM. I guess not :( TM basically gives you > transaction properties (eg, virtually atomic + isolated execution) for > ordinary program code. Thus, to make incrementing a counter thread-safe, you > could say __transaction { counter++; } and

...ttp://reviews.llvm.org/D7288> Hi Peter, I don’t think that adding an IR construct for this is the way to go. You’re making IR complicated for everyone to serve a very narrow use case (one that admittedly I don’t really understand). The fact that this affects semantics and will only work with LTO and not native linkers is also really weird to me. Is there other precedent for that? The only cases I know that affect LTO add information that is safe to drop (e.g. TBAA etc). Also, your patch is incomplete. Presumably you have to scatter checks for “if (!GV->isBitSet())” throughout the op...

On Thu, Jan 29, 2015 at 02:22:48PM -0800, Peter Collingbourne wrote: > I've been working on a patch that implements the bitset attribute and bitset > lowering pass. I'll see if I can send it out later today. http://reviews.llvm.org/D7288 Thanks, -- Peter

Hi, I would like to know whether the community is interested in getting support for Transactional Memory (TM) merged in upstream LLVM. TM basically gives you transaction properties (eg, virtually atomic + isolated execution) for ordinary program code. Thus, to make incrementing a counter thread-safe, you could say __transaction { counter++; } and the compiler would transform this code so

...ort in codegen for bitsets yet, the intrinsic is completely handled by the pass. I can't imagine the changes being very intrusive though. We can easily add a check that no bitset stuff makes it through to codegen for the moment. > The fact that this affects semantics and will only work with LTO and not native linkers is also really weird to me. I agree, which is why I plan to add support to lld and perhaps other linkers, but we do have to start somewhere. Adding the functionality to the compiler only seems like a reasonable first step, even if we depend on LTO to begin with. > Is the...

As mentioned in the Updated ThinLTO RFC ( http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/086211.html), I am sending the symbol linkage and renaming required by ThinLTO as a separate RFC. It is included below. I've also attached the doc in pdf form, since the formatting (especially for the table at the end) may not come thro...

...42 AM, Richard Smith via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Tue, Mar 8, 2016 at 8:13 AM, Rafael Espíndola >> <llvm-dev at lists.llvm.org> wrote: >> > I have just benchmarked building trunk llvm and clang in Debug, >> > Release and LTO modes (see the attached scrip for the cmake lines). >> > >> > The compilers used were clang 3.5, 3.6, 3.7, 3.8 and trunk. In all >> > cases I used the system libgcc and libstdc++. >> > >> > For release builds there is a monotonic increase in each version...

...r option for people who do not need >>> the lower instrumentation overhead. >>> >> >> This is not just about lower instrumentation overhead. Things like the >> recently added static VP node allocation (which will e.g. make indirect >> callsite promotion for LTO'd kernels work) are other things are being >> missed out on. >> >> >> >>> I would actually make the IRPGO mode completely incompatible with the >>>> -fcoverage-mapping flag. >>>> >>> >>> I'm not sure what you mean by...

...>> the lower instrumentation overhead. >>>>> >>>> >>>> This is not just about lower instrumentation overhead. Things like the >>>> recently added static VP node allocation (which will e.g. make indirect >>>> callsite promotion for LTO'd kernels work) are other things are being >>>> missed out on. >>>> >>>> >>>> >>>>> I would actually make the IRPGO mode completely incompatible with the >>>>>> -fcoverage-mapping flag. >>>>>> &gt...