similar to: [LLVMdev] [PATCH] Preserver ProfileInfo in CodeGenPrepare

Hi all! Attached a patch to preserve ProfileInfo in CodeGenPrepare. Would it be okay to commit such patches (that touch parts of LLVM to preserve ProfileInfo) without prior approval? Thanks, Andi -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-r81438.preserver.profile.info.patch Type: text/x-patch Size: 4480 bytes Desc: not available URL:

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

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

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

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

Hi, Shuguang Feng wrote: > Thanks for such a rapid response! > >> Don't know about Passes in the backend, but this could be a problem of >> an FunctionPassManager trying to use a ModulePass. > > I manually applied the patch you provided for llc (I'm using the 2.5 > release of LLVM not ToT) and it fixed my compilation error. When your > patch replaced the

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

> 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? Target Data Layout Create Garbage Collector Module Metadata

Hi all, I have some questions about the maintenance of the Profiling Code, since this is largely my contribution I still feel responsible for it. (I have not finished my master thesis, so it also is still work in progress... :-) When there are API changes in LLVM, I guess the person changing the API is responsible for changing all the occurrences in LLVM? (So I do not have to worry about

> It *is* allowed to access ModulePass analysis information from an > FunctionPass? BasicBlockPlacement (a FunctionPass) also accesses the profile information and I assumed it worked (but haven't independently verified this). > Can you try to manually override the PI value in the > MyCodeGenPass::runOnMachineFunction() to the value seen in llc and then > access the

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  

Hi, Andreas Neustifter wrote: > I'm writing a ModulePass that needs critical edges split up. I have the > statement > > AU.addRequiredID(BreakCriticalEdgesID); > > in my getAnalysisUsage() but the pass never gets executed. > > I guess I have to request pass execution for each function, but I can't > get behind how to do that, since there is no analysis group