similar to: RFC: Extending optimization reporting

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

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

> 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

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

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,

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

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

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,

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

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

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

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

> 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

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

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 instructions by dumping it to YAML files (initially) then track changes done by each pass incrementally as it is done in optimization remark emitter. Once we have required information in YAML

I would like to be able to emit a list of functions by name and their fixed stack reservation size information, so that a programmer can gauge how much stack they are likely to need in tightly constrained embedded systems. Despite the rich number of options, the only option I can find that is even relatively close is: -warn-stack-size=<uint> Is there some existing way of getting this

Reduction Not Captured By LLVM CODE_1 ------------------------------------------------------------ ------------------------------------------------------------ -------------------- #include <stdio.h> int main() { int sum[1000]={1,2,3,4}; for (int i=1;i<1000;i++) { sum[0] +=sum[i-1]; } }

Dear llvm-dev community, I am trying to analyze the optimization remarks generated through clang using -fsave-optimization-remark with -O3. --- !Analysis Pass: loop-vectorize Name: CFGNotUnderstood DebugLoc: { File: c-ray-mt.c, Line: 177, Column: 2 } Function: main Args: - String: 'loop not vectorized: ' - String: loop control flow is not understood by vectorizer I tried to look for