similar to: RFC: Combining Annotation Metadata and Remarks

Cool! I really like the idea. I left a comment about metadata preservation below. Once this is available we will certainly employ it to understand OpenMP programs better. We could also think about a user facing version of this while we are at it ;) ~ Johannes On 11/4/20 3:57 PM, Florian Hahn via llvm-dev wrote: > Hi, > > > I would like to propose a new !annotation metadata kind

> On Nov 6, 2020, at 17:32, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > > Cool! I really like the idea. I left a comment about metadata preservation below. > Once this is available we will certainly employ it to understand OpenMP programs better. That sounds like a great use case! Having multiple different uses cases during the bring-up would be very helpful to

> On Nov 9, 2020, at 19:27, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > On 11/9/20 5:09 AM, Florian Hahn wrote: >> >>> On Nov 6, 2020, at 17:32, Johannes Doerfert <johannesdoerfert at gmail.com <mailto:johannesdoerfert at gmail.com>> wrote: >>> >>> Cool! I really like the idea. I left a comment about metadata preservation

Hi Florian, On 11/9/20 5:09 AM, Florian Hahn wrote: > >> On Nov 6, 2020, at 17:32, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: >> >> Cool! I really like the idea. I left a comment about metadata preservation below. >> Once this is available we will certainly employ it to understand OpenMP programs better. > That sounds like a great use case!

Hi everyone, I frequently find that I want to quickly find out which functions have changed the most in size when I compile a program with one version of the compiler and another version of the compiler. Optimization remarks provide deeper insight into what the compiler does to individual functions during the compilation process. A tool based off of remarks would give us the means to say

Hi, There was a recent discussion on generating non-temporal stores automatically[1]. This is a hard problem to get right. What seems like a much easier but still useful problem to solve is to provide diagnostics to the user where NT stores *may* help. Then the user can add the corresponding builtins and see if they are beneficial. My hope is that with the work to add profile-driven

Hello all, According to *clang/lib/CodeGen/CodeGenFunction.cpp*, a LLVM annotation intrinsic call has 4 arguments: - llvm::Value *AnnotatedVal, - Builder.CreateBitCast(CGM.EmitAnnotationString(AnnotationStr), Int8PtrTy), - Builder.CreateBitCast(CGM.EmitAnnotationUnit(Location), Int8PtrTy), - CGM.EmitAnnotationLineNo(Location) However, this is what an annotation intrinsic *char

This new metadata format is currently optional. The old ptx_kernel calling convention should still work. The only thing you should have to change when converting from PTX -> NVPTX is the address space map. The calling conventions and intrinsics should be compatible with both. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]

> 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 everybody, I have noticed that the new NVPTX backend requires new metadata to identify the kernels in the module: define void @metadata_kernel(float* %a) { ret void } !nvvm.annotations = !{!1} !1 = metadata !{void (float*)* @metadata_kernel, metadata !"kernel", i32 1} Is clang going to support the emission of this metadata soon ? Or do I have to write it on my own ? :) Thanks,

On Jun 25, 2008, at 6:33 AM, Matthijs Kooijman wrote: > Hi all, Howdy Matthijs, > I've also been developing an interest in using IR annotations for my > compiler. > Some discussion with Bart turns out that he has implemented some > code to parse > the llvm.globals.annotations array, but in no way integrated or > reusable. > We've spent some thought about how

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

"Gerard Tromp" <gerard.tromp at sanger.med.wayne.edu> writes: > Greetings, > > this is a follow-up to the mailing below. Seth Falcon replied and indicated > that he and several others were unable to replicate the problem. > Specifically he requested: > > ============ > We are not able to reproduce this issue. If you reinstall the > annotation packages

Hi all, I've also been developing an interest in using IR annotations for my compiler. Some discussion with Bart turns out that he has implemented some code to parse the llvm.globals.annotations array, but in no way integrated or reusable. We've spent some thought about how this could be done properly, which I will share here. Firstly, however, I was wondering about the format of the

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

Hi, Here it is, just synched against the latest LLVM trunk. Shall I commit this now? After committing, it could be worth some planning what is the best way to provide an easy to use mechanism to "refresh" the parallel loop mem access metadata (llvm.mem.parallel_loop_access) after optimizations that do not render the loop to a serial one. Some kind of helper function should be added to

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