similar to: [LLVMdev] ProfileInfo Questions -- How to proceed?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, since I'm planing on a whole bunch of changes in the area of the Profiling Infrastructure I would like to ask humbly if it is possible to have approve-after-commit permission for the following files: include/llvm/Analysis/ProfileInfo.h include/llvm/Analysis/ProfileInfoLoader.h include/llvm/Analysis/ProfileInfoTypes.h

Hello, Here are a few misc. comments on this patch. Would it make sense to mark the ProfileInfo passes as "CFGOnly?" If so, that would let them be automatically preserved by passes which don't modify the CFG (and that call AU.setPreservesCFG()). > + if (ProfileInfo* PI = getAnalysisIfAvailable<ProfileInfo>()) { > + PI->splitEdge(OrigPreHeader, NewHeader,

Hi all, this (altough a big patch) is actually pretty straight forward: It (tries) to preserve ProfileInfo in all -std-compile-opts passes and all X86-Backend passes. There is still some passes that have corner cases where the ProfileInfo is not correct after the pass. Some passes are still missing... How shall I proceed with this? Andi -------------- next part -------------- A non-text

Hi. On 11/17/2009 08:16 PM, Andreas Neustifter wrote: > Hi, > > Devang Patel wrote: >> On Tue, Nov 17, 2009 at 9:03 AM, Andreas Neustifter >> <astifter-llvm at gmx.at> wrote: >> >>> Okay, so the ProfileInfoLoader is working, but when I examine the executions more closely I see that the ProfileInfo generated by the ProfileInfoLoader is immediately

Hi, Devang Patel wrote: > On Tue, Nov 17, 2009 at 9:03 AM, Andreas Neustifter > <astifter-llvm at gmx.at> wrote: > >> Okay, so the ProfileInfoLoader is working, but when I examine the executions more closely I see that the ProfileInfo generated by the ProfileInfoLoader is immediately discarded, when the SelectionDAGISel kicks in the "No Profile Info"-Implementation

Hi all! On 11/20/2009 06:29 PM, Devang Patel wrote: > > On Fri, Nov 20, 2009 at 6:54 AM, Andreas Neustifter wrote: >> >> If I use AU.addRequired<ProfileInfo>() in SelectionDAGISel.cpp the >> wrong ProfileInfo is used. It uses the "No ProfileInfo" implementation >> if ProfileInfo but not the one from ProfileInfoLoaderPass. (Which is >>

On Fri, Nov 20, 2009 at 6:54 AM, Andreas Neustifter <astifter-llvm at gmx.at> wrote: > > If I use  AU.addRequired<ProfileInfo>() in SelectionDAGISel.cpp the > wrong ProfileInfo is used. It uses the "No ProfileInfo" implementation > if ProfileInfo but not the one from ProfileInfoLoaderPass. (Which is > immediately discarded after creation.) > You need to

Hi! On 12/03/2009 07:50 PM, Dan Gohman wrote: > Hello, > > Here are a few misc. comments on this patch. > > Would it make sense to mark the ProfileInfo passes as "CFGOnly?" > If so, that would let them be automatically preserved by passes > which don't modify the CFG (and that call AU.setPreservesCFG()). Yes, it would, how do I do this? :-) >> +

Hi, when I try to build libprofile with r80670 (both llvm and llvm-gcc) I get this error: make[1]: Entering directory `.../llvm-svn-debug-obj/runtime/libprofile' llvm[1]: Building Debug Bytecode Archive libprofile_rt.bca (internalize) llvm[1]: Installing Debug Shared Library /nfs/a5/astifter/astifter/llvm/llvm-svn-debug-obj/../llvm-svn-debug-install/lib/libprofile_rt.so 0 llvm-ld

Hi all, after some work I finally am able to preserve the ProfileInfo in quite some passes. My first question is how to deal with this patch. I have touched quite some code, everywhere are scattered bits of "preserving code" and a quite some additions to the ProfileInfo-API. I guess checking in the ProfileInfo part is not a problem, but how shall I proceed with all the code in the

Hi Chandler and Alastair, I have been using the Profile.pl and the related passes and optimizations for about 4 years now. With every new release lately, the support for the profile scripts and their framework seemed to be downgrading. Hence, I used my own tiny one line fixes to keep them working. I offered to send these small patches to keep these scripts working, to the LLVM dev so that others

Hi Chandler, I'm a GSoC student working on profiling support (mentor CC'ed). I'm no stranger to the issues with the current system: my original proposal was written without knowledge of the limitations. This is why this list hasn't heard much from me yet. I would like to continue working on profiling support but I'm not attached to ProfileInfo and wouldn't be

Hi, I'm fighting with this quite some time now: Is there a way to mark an Analysis (in my case ProfileInfo) as perserved by _all_ passes? I have tried to add ProfileInfo directly in Pass.h:getAnalysisUsage() but that produces nasty circular library dependecies. I also tried to simply store a pointer to the ProfileInfo in Module but then the PassManager gets confused resulting in double

Hi, I have trouble making my ProfileInfo-Analysis available in the backend, I have changed llc so it loads the ProfileInfo if requested, the PassManger gives this output: > Target Data Layout > Create Garbage Collector Module Metadata > Basic Alias Analysis (default AA impl) > DWARF Information Writer > No Profile Information > Module Information > ModulePass

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, the second part of my work is to preserve the profiling information through all the transformation passes and make it available to the backend machinery. Attached is an example patch on how I plan to preserve the information for a given transformation pass. And now comes the question into place: whats the best way to attach the profile info

Shuguang Feng wrote: >> What does "llc -debug-pass=Structure" say? Is the ProfileLoaderPass >> really the last pass to touch the ProfileInfo before you are using it? > > Below is the sequence of passes that I see. Although the > NoProfileInfo pass is being run, it should be subsequently overridden > by ProfileInfoLoaderPass (LoaderPass) correct? Yes. >

On Sep 8, 2009, at 1:27 AM, Andreas Neustifter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > the second part of my work is to preserve the profiling information > through all the transformation passes and make it available to the > backend machinery. > > Attached is an example patch on how I plan to preserve the information > for a given

On Sun, Jul 15, 2012 at 8:32 AM, Alastair Murray <alastairmurray42 at gmail.com > wrote: > Hi Chandler, > > I'm a GSoC student working on profiling support (mentor CC'ed). I'm no > stranger to the issues with the current system: my original proposal was > written without knowledge of the limitations. This is why this list > hasn't heard much from me yet.

On Tue, Nov 17, 2009 at 9:03 AM, Andreas Neustifter <astifter-llvm at gmx.at> wrote: > > Okay, so the ProfileInfoLoader is working, but when I examine the executions more closely I see that the ProfileInfo generated by the ProfileInfoLoader is immediately discarded, when the SelectionDAGISel kicks in the "No Profile Info"-Implementation is used: > >  > 0x1c1a740  

On Wed, Jul 1, 2009 at 2:36 AM, Andreas Neustifter<e0325716 at student.tuwien.ac.at> wrote: >> [...] >> >> 1. The intent of ProfileInfo is that it is the public interface used by the rest >> of LLVM for all "profiling" related analyses. As such, we want it to have a >> thin, well-defined interface which can be implemented by multiple analysis >>