search for: dofin

I'm wondering if the documentation for LoopPass ( http://llvm.org/docs/WritingAnLLVMPass.html#LoopPass) is misleading or incorrect (or if I'm just missing something.) The documentation states: "The doFinalization method ... is called when the pass framework has finished calling runOnLoop<http://llvm.org/docs/WritingAnLLVMPass.html#runOnLoop> for every loop in the program being compiled." >From this, I understood that for a single instance of a LoopPass sub-class, the doFinalization m...

...rgument to see what passes run after your pass)?* I considered that for a moment, but I realized that wouldn't be possible for two reasons: I specifically ran my pass with opt level zero; and one of the tasks I was doing was removing unused prototypes from the Module -- so, why would any other doFinalization pass reintroduce those prototypes if those functions were not being invoked anywhere? (PS: since this clean-up happened inside my doFinalization, I'm assuming only other doFinalization would be able to change the module after this point) *Also, does your doFinalization() method make...

Hi Stephen, On 13/12/12 18:58, Stephen McGruer wrote: > I'm wondering if the documentation for LoopPass > (http://llvm.org/docs/WritingAnLLVMPass.html#LoopPass) is misleading or > incorrect (or if I'm just missing something.) The documentation states: > > "The doFinalization method ... is called when the pass framework has finished > calling runOnLoop <http://llvm.org/docs/WritingAnLLVMPass.html#runOnLoop> for > every loop in the program being compiled." > > From this, I understood that for a single instance of a LoopPass sub-class, the...

On 5/6/15 11:15 AM, Kuperstein, Michael M wrote: > > I’ve always thought that the only guarantee is that > doFinalization(Module &M) runs after runOnFunction() was executed for > all functions in M, and there’s no guarantee it runs *immediately* after. > > That is, a PM may run a bunch of function passes over each function, > and only then call doFinazliation() for each pass. That means that...

On 5/6/15 10:19 AM, Kuperstein, Michael M wrote: > > Hello Cristiano, > > I don’t think doFinalization() is really meant to be used this way. > My understanding is that doInitialization() and doFinalization() are designed specifically for modifying the LLVM IR (otherwise, why would a mutable reference to the Function be provided)? If that is not the case, then there is either a bug i...

Hello All, There is an issue in AddressSanitizer today because it depends on it's doFinalization method be called before the Printer method to output the final code (that is the printer runOnModule call). This assumption seems invalid as the doFinalization method should AFAIK only be used for clean up tasks independent of activities of other passes. When I try to call doFinalization...

...f the documentation for LoopPass >> (http://llvm.org/docs/**WritingAnLLVMPass.html#**LoopPass<http://llvm.org/docs/WritingAnLLVMPass.html#LoopPass>) >> is misleading or >> incorrect (or if I'm just missing something.) The documentation states: >> >> "The doFinalization method ... is called when the pass framework has >> finished >> calling runOnLoop <http://llvm.org/docs/**WritingAnLLVMPass.html#** >> runOnLoop <http://llvm.org/docs/WritingAnLLVMPass.html#runOnLoop>> for >> >> every loop in the program being comp...

...tation for LoopPass > (http://llvm.org/docs/__WritingAnLLVMPass.html#__LoopPass > <http://llvm.org/docs/WritingAnLLVMPass.html#LoopPass>) is misleading or > incorrect (or if I'm just missing something.) The documentation states: > > "The doFinalization method ... is called when the pass framework has > finished > calling runOnLoop > <http://llvm.org/docs/__WritingAnLLVMPass.html#__runOnLoop > <http://llvm.org/docs/WritingAnLLVMPass.html#runOnLoop>> for > > every loop i...

Hello there, I'm writing some LLVM passes, and just ran into an interesting situation: now, I don't know if I misunderstood the way doFinalization is supposed to work, but I hope someone could help =) One of the transformations I wrote needed to replace some instructions within the code, so I needed to clean up the code after the process was completed. The pass basically swapped some function calls (from the standard C library) with...

I have a FunctionPass F that needs a list of all the SCCs for use in its doFinalization() method. Let's say I write a CallGraphSCCPass C that creates an array of all SCCs. Let C be required by F, and let F call getAnalysis<C>() from its doFinalization() method. Am I guaranteed that C's runOnSCC() method will have executed on all SCCs before F's doFina...

Hi all, I find all my passes are all broken with LLVM 3.4. Then I tried out the LLVMHello.so specified in the LLVM doc, http://llvm.org/docs/WritingAnLLVMPass.html and it also crashes. It seems all the functions in the pass do work, but LLVM crashes in the doFinalization() step. Does anyone know this problem? Thanks! Tianyin ----------------------------------------------------------------------------------------------------------------- #opt -load ../../../Debug+Asserts/lib/LLVMHello.so -hello -time-passes < bcfiles/hello.bc ... (PRINT ALL THE FUNCT...

...p) is empty and, thus, GCMetadataPrinter::finishAssembly is never called. > Right now there is a pass whose only job is to delete that information (CGInfoDeleter) and that pass deletes the info before the AsmPrinter has a chance to call the finishAssembly function. Right now the order that the doFinalization is called on passes is the reverse order of doInitialization (and that makes sense as if a pass depends on some other pass it has to initialize after that pass and clean up before it) so the deleter pass would have to be added in the pass order after the AsmPrinter pass as that pass clearl...

As discussed in LLVMdev [1], due to the execution order of doFinalization functions, the GC information were deleted before AsmPrinter::doFinalization was executed. Thus, the GCMetadataPrinter::finishAssembly was never called. The attached patch fixes that by moving the code of the GCInfoDeleter::doFinalization to Printer::doFinalization. Pedro (cc'ed) has...

Hello Yiannis, I am not an expert on metadata or the CG information but one of the two has to happen: - Simply moving the deleter pass to a different spot - Changing the doFinalization of another pass (Printer?) to do the deleter pass job (this should work now because the doFinalization order is the reverse of the doInitialization order) Option 1 is a smaller change, option 2 will make the code cleaner and prevent issues like this in the future, so it sounds like a bett...

...l my passes are all broken with LLVM 3.4. Then I tried out the > > LLVMHello.so specified in the LLVM doc, > > http://llvm.org/docs/WritingAnLLVMPass.html > > and it also crashes. > > > > It seems all the functions in the pass do work, but LLVM crashes in the > > doFinalization() step. > > > > Does anyone know this problem? > > > > Thanks! > > Tianyin > > > > > ----------------------------------------------------------------------------------------------------------------- > > > > #opt -load ../../../Debug+...

...sponsible for this is: > d1abec365aa89a8497d9b615ccb4b21c72da9447 is the first bad commit > commit d1abec365aa89a8497d9b615ccb4b21c72da9447 > Author: Pedro Artigas <partigas at apple.com> > Date: Wed Dec 5 17:12:22 2012 +0000 > > - Added calls to doInitialization/doFinalization to immutable passes > - fixed ordering of calls to doFinalization to be the reverse of the pass run order due to potential dependencies > - fixed machine module info to operate in the doInitialization/doFinalization model, also fixes some FIXMEs > > reviewed by E...

I have a whole slew of questions about optimization passes. Answers to any or all would be extremely helpful: How important are doInitialization/doFinalization? I can't detect any difference if I use them or not. Why does the function pass manager have doInitialization/doFinalization, but the global pass manager doesn't? If I am applying the function passes to many functions, do I doInitialization/run/doFinalization for each function I...

no... I guess verifier runs by default and it points to the doFinailization() function :-( ~t On Tue, Aug 12, 2014 at 12:53 AM, Eric Christopher <echristo at gmail.com> wrote: > No idea, I was suggesting to just run the verifier to see if it would > pinpoint what's broken about the module. > > -eric > > On Tue, Aug 12, 2014 at 12:5...

...there is an issue with the way that information is deleted (the CG information). Right now there is a pass whose only job is to delete that information (CGInfoDeleter) and that pass deletes the info before the AsmPrinter has a chance to call the finishAssembly function. Right now the order that the doFinalization is called on passes is the reverse order of doInitialization (and that makes sense as if a pass depends on some other pass it has to initialize after that pass and clean up before it) so the deleter pass would have to be added in the pass order after the AsmPrinter pass as that pass clearl...

Hi all, Currently, debug info verifier is part of the IR verifier which is a function pass. One part of the IR verifier that I don't like is it verifies module-level data in doFinalization. If we have two verifier passes in a single module pass manager, doFinalization of the two passes will run on the same module data after all passes. I followed the same model for debug info verifier: verifying debug info reachable from a function in runOnFunction and verifying module leve...