similar to: Rewriting opt-viewer in C++

If the decision on whether this should swing Python or C++ is still open, here’s some food for thought: it’s trivially parallelizable. I lobbed some stuff in https://reviews.llvm.org/D26789 I used the pure python PyYAML and got a speedup of ~4x on my test case. I expect you might still be able to get an improvement with libYAML + a patch like this one. FWIW prior to this I also tried PyPy

> On Nov 15, 2016, at 10:33 AM, Bob Haarman <inglorion at google.com> wrote: > > Thanks for your comments, everyone! I'll try to answer the questions people have asked. First, let me say that I like Python, so I would be happy to keep the tool in Python if people feel that is a better way to go and we can still get it to go fast. As for precedent, we have several Python scripts

Again I am still undecided which way this should go but I was also wondering about the speed difference if we used the C-based parser in PyYAML (http://pyyaml.org/wiki/LibYAML <http://pyyaml.org/wiki/LibYAML>). > On Nov 13, 2016, at 12:19 AM, Adam Nemet <anemet at apple.com> wrote: > > Hi Bob, > > I am glad you’re finding opt-viewer useful. I am generally fine this

That's compared to the implementation with the Python parser. So if the libYAML parser is 6x the speed of that, the C++ version would be about 10x the speed of the implementation with libYAML, instead of 60x. On Tue, Nov 15, 2016 at 10:50 AM, Adam Nemet <anemet at apple.com> wrote: > > On Nov 15, 2016, at 10:33 AM, Bob Haarman <inglorion at google.com> wrote: > >

Adam, The test case was the Python-3.6.0b3 release, 234 input YAML files. The large majority of time is spent with processing the file input. Next ranked was rendering output. Moving the files to a tmpfs partition didn’t change the time significantly (but I would expect that experiment would yield different results with libYAML). original, single-threaded: processed input files

> On Jul 14, 2017, at 8:21 AM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, Jun 19, 2017 at 4:13 PM, Brian Gesiak via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> Hello all, >> >> In https://www.youtube.com/watch?v=qq0q1hfzidg, Adam Nemet (cc'ed) describes >>

> On Jul 14, 2017, at 10:22 AM, Davide Italiano <davide at freebsd.org> wrote: > > On Fri, Jul 14, 2017 at 10:10 AM, Adam Nemet <anemet at apple.com <mailto:anemet at apple.com>> wrote: >> >> >> On Jul 14, 2017, at 8:21 AM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On Mon, Jun 19, 2017 at 4:13 PM, Brian

Hello all, In https://www.youtube.com/watch?v=qq0q1hfzidg, Adam Nemet (cc'ed) describes optimization remarks and some future plans for the project. I had a few follow-up questions: 1. As an example of future work to be done, the talk mentions expanding the set of optimization passes that emit remarks. However, the Clang User Manual mentions that "optimization remarks do not really make

Hey all, I'm attempting to upgrade a Centos 5.9 machine to CentOS 5.10. But when I try the yum update command I get this response: --> Finished Dependency Resolution python26-PyYAML-3.08-5.el5.x86_64 from installed has depsolving problems --> Missing Dependency: libyaml-0.so.1()(64bit) is needed by package python26-PyYAML-3.08-5.el5.x86_64 (installed) --> Running transaction

I'm sorry, but I don't think LLDB has any release notes. On Sat, Aug 26, 2017 at 9:49 PM, Kamil Rytarowski <n54 at gmx.com> wrote: > LLDB: > > Switched the NetBSD platform to new remote tracing capable framework. > > Preliminary support for tracing NetBSD(/amd64) processes and core files > with a single thread. > > On 25.08.2017 02:44, Hans Wennborg via

Thanks! r311738. On Thu, Aug 24, 2017 at 4:51 PM, Adam Nemet <anemet at apple.com> wrote: > Hi Hans, > > Opt-viewer is now installed rather than being an internal-only tool so here it goes: > > A new tool opt-viewer.py has been added to visualize optimization remarks in HTML. The tool processes the YAML files produced by clang with the -fsave-optimization-record option. >

> On Wed, Jun 28, 2017 at 8:13 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > I don't object to adding some kind of filtering option, but in general it won't help. An important goal here is to provide analysis (and other) tools to users that present this information at a higher level. The users won't, and shouldn't, know exactly what kinds of messages the tools use.

On Tue, May 30, 2017 at 12:52 PM Bob Haarman <llvm at inglorion.net> wrote: > I would like to better understand how you came to conclude that the > tablegen re-runs based on changes in Support are what's causing your build > to be slow and what part specifically is taking all that time. I can do a > clean release + assertions build of LLVM, Clang, compiler-rt and lld in >

> On Mar 15, 2017, at 2:30 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > On 03/15/2017 04:05 PM, Adam Nemet wrote: >> >>> On Mar 15, 2017, at 2:00 PM, Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote: >>> >>> >>> On 03/15/2017 01:47 PM, Adam Nemet wrote: >>>> >>>>> On Mar

On Thu, Mar 10, 2016 at 1:17 AM, Adam Nemet <anemet at apple.com> wrote: > I’ve committed the fix in r263058. Haicheng, Eric/Benjamin, can you guys > please give it a test with your codebase. (You need to enable the pass with > -mllvm -enable-loop-load-elim.) The miscompilation I was seeing is gone now, too. Thanks! > On Mar 7, 2016, at 11:05 PM, Adam Nemet <anemet at

> On Mar 7, 2016, at 9:43 AM, Adam Nemet <anemet at apple.com> wrote: > > Hi Haicheng, > > Sorry about the breakage. I reverted it in r262839. > > I will try to reproduce it locally. Please don’t blow away your directories yet in case I need further help. OK, I managed to reproduce this locally. Should be able to make progress from here without further help from

Hello! (+cc Adam Nemet, since he presented on optimization remarks at LLVM Dev Mtg 2016) I have a large C++ program, which I am compiling using a sampling profile generated via perf and AutoFDO. I'd like to use this profile in order to show the hotness of each code path that is displayed in the new optimization remarks viewer tool ( https://www.youtube.com/watch?v=qq0q1hfzidg). It seems,

Thank you, Adam. It passes all the benchmarks I have. Haicheng From: anemet at apple.com [mailto:anemet at apple.com] Sent: Wednesday, March 09, 2016 7:17 PM To: Haicheng Wu; Eric Christopher; Benjamin Kramer Cc: llvm-dev Subject: Re: Regression in SPEC2006/gcc caused by LoopLoadElimination I’ve committed the fix in r263058. Haicheng, Eric/Benjamin, can you guys please give it a

On 03/16/2017 04:13 PM, Adam Nemet wrote: > >> On Mar 15, 2017, at 2:51 PM, Adam Nemet <anemet at apple.com >> <mailto:anemet at apple.com>> wrote: >> >>> >>> On Mar 15, 2017, at 2:30 PM, Hal Finkel <hfinkel at anl.gov >>> <mailto:hfinkel at anl.gov>> wrote: >>> >>> >>> On 03/15/2017 04:05 PM, Adam

Doesn't that just tell it what tablegen to use? I was looking for an option to make it not run *anything*, and just assume that all tablegen definitions were up to date On Tue, May 30, 2017 at 2:27 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > 2017-05-30 13:50 GMT-07:00 Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org>: > >> >> >> On Tue,