similar to: Next steps for optimization remarks?

> 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! (+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,

Adam, thanks for all the suggestions! One nice aspect of the `-Rpass` family of options is that I can filter based on what I want. If I only want to see which inlines I missed, I could use `clang -Rpass-missed="inline"`, for example. On the other hand, optimization remark YAML always include remarks from all passes (as far as I can tell), which increases the amount of time it takes

> 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.

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

I would like to begin a discussion about updating LLVM's opt-report infrastructure. There are some things I'd like to be able to do with optimization reports that I don't think can be done, or at least aren't natural to do, with the current implementation. I understand that there is a lot of code in place already to produce optimization remarks, and one of my explicit goals is to

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

Hi, I'm new to llvm and am trying to run benchmarks from the test-suite using lnt to check loop-vectorization for various benchmarks. Test are compiling and executing fine, but I am not getting optimization remarks while using flags like -Rpass-missed=loop-vectorize and -Rpass-analysis=loop-vectorize I've tried running it like this: lnt runtest test-suite --sandbox SANDBOX --cc

> On May 11, 2016, at 3:37 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > ----- Original Message ----- >> From: "Adam Nemet" <anemet at apple.com> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: "llvm-dev (llvm-dev at lists.llvm.org)" <llvm-dev at lists.llvm.org> >> Sent: Wednesday, May 11, 2016 1:15:42 AM

> 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

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. >

Hi Adam, Thanks for your input. If I understand correctly, you’re saying that we can handle the loop versioning issue by explicitly identifying new loops as they are created. So, the unswitching optimization, for example, would report that it unswitched loop-0 at source location X, creating loop-1 and loop-2, and then later the vectorizer would report that it was unable to vectorize loop-1 at

Hi Hal, > On May 10, 2016, at 5:39 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > Hi Adam, > > I think would be a really useful feature to have. I don't think that the backend should be responsible for filtering, but should pass the relative hotness information to the frontend. Given that these diagnostics are not just going to be used for -Rpass and friends, but also

Dear everyone, We're a couple of release candidates into the process, and the release notes are not in very good shape: http://prereleases.llvm.org/5.0.0/#rc2 If you committed anything noteworthy in the last six months, or saw someone else do it, please consider adding it to the release notes. People do read them. If you're responsible for a specific CPU target, please help give those

Hi all, I tried to poke my head into opt-report a while ago and didn't get very far. Now I'm looking at it again. I'm not sure I understand everything that's in place so my question here may be misguided. I'm trying to understand the way strings are handled. When a remark is emitted, it seems that the string is constructed on the fly based on streaming inputs. For example,

Hi Adam, Thank you for writing opt-viewer! I've been playing around with it and found it helps me understand what optimizations were performed, which were missed, and why, as well as easily navigate to the relevant code. Wanting to use it on larger projects, I found that it can take a while to analyze the optimization reports. Since there doesn't seem to be too much code in it yet, I

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: > >

> On May 5, 2017, at 8:49 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > > On 05/05/2017 10:44 AM, vivek pandya via llvm-dev wrote: >> Hello LLVM Devs, >> >> I have an idea to improve effectiveness of IR dump with -emit-after-all based on Adam Nemet's 2016 LLVM Dev presentation. >> I think we can track changes in each function, basic block and