similar to: [LLVMdev] Confusing buildbot failure in LLVM on sanitizer-x86_64-linux

On Wed, May 13, 2015 at 10:39 AM, Reid Kleckner <rnk at google.com> wrote: > It's a 20m timeout without output. > > If you back up to the build and look at the 'annotate' step output, > there's this text: > > http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/17916/steps/annotate/logs/stdio > > -- Testing: 258 tests, 16 threads -- >

+dvyukov On Wed, May 13, 2015 at 11:08 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Wed, May 13, 2015 at 10:39 AM, Reid Kleckner <rnk at google.com> wrote: > >> It's a 20m timeout without output. >> >> If you back up to the build and look at the 'annotate' step output, >> there's this text: >> >>

Happened to me again: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/18273/steps/annotate/logs/stdio In fact, this whole bot has a 20% failure rate with the same failure mode, from looking at the history: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/?numbuilds=50 They all end with this: [100%] Running ThreadSanitizer tests -- Testing: 258 tests, 16 threads --

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.

You need llvm-symbolizer in PATH. On Apr 11, 2014 3:16 AM, "Diego Novillo" <dnovillo at google.com> wrote: > OK, so now I've gotten a build but the output from asan is less than > helpful: > > $ llvm/x/llvm_build_asan/./bin/opt llvm/x/llvm/test/Other/optimization-remarks-inline.ll > -inline -pass-remarks=inline -S >

I recently broke a sanitizer buildbot but I am unable to reproduce the failure. The buildbot that failed is http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/2959 I looked around in the logs, looking for the config/build commands that would reproduce the failure. The problem is that the bot seems to be using a script which I don't have access to

Hi Ehsan, In some cases modulo scheduling will insert copy instruction that end up as real copies in the final code. It unavoidable in some cases. For example, let's say a instruction defining a value is scheduled in the first iteration, but one of its uses is scheduled two iterations later. In this case, the kernel needs to create a copy because there will be two values live in the

On 06/06/2014 02:33, Alexey Samsonov wrote: > Hi Alp, > > This warning should be fixed by r210301. However, consider > investigating why the frame size appears to be that large. I believe > we build this code with GCC as well and have seen no complaints > from its implementation of -Wframe-larger-than. CC'ing in llvmdev. Like Chandler said it could just be due to lack of

Hi James, I also think that refactoring the code generation part is a great idea. That code is very complicated and difficult to maintain. I’ve wanted to rewrite that code for a long time, but just have never got to it. There are quite a few edge cases to handle (at least in the current code). I’ll take a deeper look at your patch. The abstractions that you mention, Stage and Block, are good

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 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 Wed, Dec 9, 2015 at 3:14 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > Can you extract the relevant part of the heap profile data? > It's all profile data, actually. The heap utilization is massively dominated by the profile reader. > How large is the sample profile data fed to the compiler? > > For this run, the input file was 21Mb. > The

On Sun, Oct 26, 2014 at 4:59 PM, Eric Christopher <echristo at gmail.com> wrote: > On Fri, Oct 24, 2014 at 3:27 PM, Diego Novillo <dnovillo at google.com> > wrote: > > > > > > 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

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

> 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 Fri, Apr 24, 2015 at 12:29 PM, Diego Novillo <dnovillo at google.com> wrote: > > > On Fri, Apr 24, 2015 at 3:28 PM, Xinliang David Li <davidxl at google.com> > wrote: >> >> yes -- for count representation, 64 bit is needed. The branch weight >> here is different and does not needs to be 64bit to represent branch >> probability precisely. > >

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 context of this is performance analysis of generated code. My interest is to trace at a high-level the major decisions done by the various optimizers. For instance, when the inliner decides to inline foo into bar, or the loop unroller decides to unroll a loop N times, or the vectorizer decides to vectorize a loop body. Many of these details are usually available via -debug-only. However, this

On Sun, Oct 26, 2014 at 3:47 PM, Jeremy Lakeman <Jeremy.Lakeman at gmail.com> wrote: > This sounds like a problem best solved by tracking source code movement via > your source control system. > If you know the commit of the code that produced the sample, you should be > able to use source control history / diffs to translate absolute line > numbers to the location where the