similar to: [LLVMdev] RFC - Adding an optimization report facility?

----- Original Message ----- > From: "Chris Lattner" <clattner at apple.com> > To: "Diego Novillo" <dnovillo at google.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, March 6, 2014 5:54:02 PM > Subject: Re: [LLVMdev] RFC - Adding an optimization report facility? > > > On Mar 6, 2014, at

On Thu, Mar 6, 2014 at 2:44 PM, Tobias Grosser <tobias at grosser.es> wrote: as others already pointed out, I committed the first piece of such an > infrastructure in LLVM commit 202474 and clang commit 202475. This is > mostly the backend and printing infrastructure. > Thanks, Tobias. I've browsed the two patches and I think they're going to be exactly what I need.

I am starting to use the sample profiler to analyze new performance opportunities. The loop unroller has popped up in several of the benchmarks I'm running. In particular, libquantum. There is a ~12% opportunity when the runtime unroller is triggered. This helps functions like quantum_sigma_x (http://sourcecodebrowser.com/libquantum/0.2.4/gates_8c_source.html#l00149). The function accounts

On 16/01/2014, 23:47 , Andrew Trick wrote: > > On Jan 15, 2014, at 4:13 PM, Diego Novillo <dnovillo at google.com > <mailto:dnovillo at google.com>> wrote: > >> Chandler also pointed me at the vectorizer, which has its own >> unroller. However, the vectorizer only unrolls enough to serve the >> target, it's not as general as the runtime-triggered

> On 2015 May 27, at 07:42, Diego Novillo <dnovillo at google.com> wrote: > > On Tue, May 26, 2015 at 11:47 PM, Lee Hunt <leehu at exchange.microsoft.com> wrote: > >> For example, from reading different pages on how Clang PGO, it’s unclear if >> it does “block reordering” (i.e. moving unexecuted code blocks to a distant >> code page, leaving only ‘hot’

> On Mar 2, 2015, at 4:19 PM, Diego Novillo <dnovillo at google.com> wrote: > > On Thu, Feb 26, 2015 at 6:54 PM, Diego Novillo <dnovillo at google.com <mailto:dnovillo at google.com>> wrote: > > I've created a few bugzilla issues with details of some of the things I'll be looking into. I'm not yet done wordsmithing the overall design document.

> On Mar 24, 2015, at 10:53 AM, Diego Novillo <dnovillo at google.com> wrote: > > On Tue, Mar 24, 2015 at 1:48 PM, Bob Wilson <bob.wilson at apple.com> wrote: >> >>> On Mar 24, 2015, at 10:27 AM, Xinliang David Li <davidxl at google.com> wrote: >>> >>> 2.3) remove the 'laplace rule of succession' which can be very harmful

On 05/27/2015 11:13 AM, Duncan P. N. Exon Smith wrote: >> On 2015 May 27, at 07:42, Diego Novillo <dnovillo at google.com> wrote: >> >> On Tue, May 26, 2015 at 11:47 PM, Lee Hunt <leehu at exchange.microsoft.com> wrote: >> >>> For example, from reading different pages on how Clang PGO, it’s unclear if >>> it does “block reordering” (i.e. moving

I have started looking at the state of PGO (Profile Guided Optimization) in LLVM.**I want to discuss my high-level plan and make sure I'm not missing anything interesting out. I appreciate any feedback on this, pointers to existing work, patches and anything related to PGO in LLVM. I will be keeping changes to this plan in this web document

On 2015 Jun 17, at 13:53, Diego Novillo <dnovillo at google.com> wrote: > The flags -fprofile-generate and -fprofile-use are currently ignored > for GCC compatibility. I would like to enable them and give them > similar semantics to GCC. These flags are baked pretty deeply into > our build environment, so supporting them at the driver level will > make our lives a lot

The flags -fprofile-generate and -fprofile-use are currently ignored for GCC compatibility. I would like to enable them and give them similar semantics to GCC. These flags are baked pretty deeply into our build environment, so supporting them at the driver level will make our lives a lot simpler. >From https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html:

On Mar 13, 2014, at 5:48 AM, Diego Novillo <dnovillo at google.com> wrote: > On Wed, Mar 12, 2014 at 9:09 PM, Justin Bogner <mail at justinbogner.com> wrote: > >> Functions are represented by strings, determined by the part of the >> frontend that both generates and uses this data. In our case, these are >> generally whatever clang thinks of as the

On Fri Oct 24 2014 at 6:21:14 PM David Blaikie <dblaikie at gmail.com> wrote: > On Fri, Oct 24, 2014 at 3:16 PM, Diego Novillo <dnovillo at google.com> > wrote: > >> >> >> On Fri Oct 24 2014 at 6:11:21 PM David Blaikie <dblaikie at gmail.com> >> wrote: >> >>> On Fri, Oct 24, 2014 at 2:48 PM, Diego Novillo <dnovillo at

On Thu, Jan 16, 2014 at 9:26 AM, Nadav Rotem <nrotem at apple.com> wrote: > Hi Diego, > > It looks like the problem is with the code in the vectorizer that tries to estimate the most profitable vectorization factor: > >> LV: Found an estimated cost of 6 for VF 2 For instruction: %3 = load >> i64* %state, align 8, !dbg !58, !tbaa !61 > > > It looks like a

> On Mar 24, 2015, at 12:08 PM, Xinliang David Li <davidxl at google.com> wrote: > > On Tue, Mar 24, 2015 at 10:54 AM, Bob Wilson <bob.wilson at apple.com> wrote: >> >>> On Mar 24, 2015, at 10:53 AM, Diego Novillo <dnovillo at google.com> wrote: >>> >>> On Tue, Mar 24, 2015 at 1:48 PM, Bob Wilson <bob.wilson at apple.com> wrote:

We (Google) have started to look more closely at the profiling infrastructure in LLVM. Internally, we have a large dependency on PGO to get peak performance in generated code. Some of the dependencies we have on profiling are still not present in LLVM (e.g., the inliner) but we will still need to incorporate changes to support our work on these optimizations. Some of the changes may be addressed

Alexey, I got mail from one of the tsan buildbots, claiming a breakage in tsan tests. But I cannot see anything on the logs it has for the build. http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/17916/steps/run%2064-bit%20tsan%20unit%20tests/logs/stdio Any ideas? Thanks. Diego. ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Wed,

On Thu, Apr 10, 2014 at 4:43 PM, Reid Kleckner <rnk at google.com> wrote: > msan isn't usable without an instrumented C++ standard library. > > The script in question is here: > > https://code.google.com/p/address-sanitizer/source/browse/trunk/build/scripts/slave/buildbot_bootstrap.sh > Thanks, Reid. I've gotten the script and I'm now running it locally.

Thanks, Marco! If there is enough interest in this topic we can also organize a separate round table for this discussion. Cheers, Anastasia ________________________________ From: Marco Antognini <Marco.Antognini at arm.com> Sent: 18 October 2019 14:42 To: Anastasia Stulova <Anastasia.Stulova at arm.com>; Simone Atzeni via llvm-dev <llvm-dev at lists.llvm.org>; clang developer

On Fri, Dec 11, 2015 at 9:58 AM, Diego Novillo <dnovillo at google.com> wrote: > So, I traced it down to the DenseMaps in class FunctionSamples. I've > replaced them with two std::vector, and the read operation causes the > compiler to grow from 70Mb to 280Mb. With the DenseMaps, reading the > profile causes the compiler to grow from 70Mb to 3Gb. > > Somehow the