similar to: [LLVMdev] AddressSanitizer depends on order of doFinalization

Sorry for the triple-posting! :-$ On 02/14/2013 04:30 PM, Yiannis Tsiouris wrote: > On 02/10/2013 08:47 PM, Yiannis Tsiouris wrote: >> After rebasing my local LLVM repo to ToT, I noticed that the >> finishAssembly function is not executed and, thus, the stack map is not >> printed at all. >> >> Is this a known issue or I 'm doing something wrong? >>

On 02/15/2013 07:13 PM, Pedro Artigas wrote: > I am not an expert on metadata or the CG information but one of the two has to happen: I'm not an expert either but I'll give it a try! :-) > - 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

Hello Yiannis, I believe what is going on is that 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

Pedro, Yiannis, What's about the usage case, when LLVM is used as a library and the user implements its custom pass, which dump the code (implemented as a FunctionPass, but not as Printer)? You also missed in your changes the declaration of llvm::createGCInfoDeleter() in include/llvm/CodeGen/Passes.h -Dmitry. On Mon, Feb 18, 2013 at 9:34 PM, Pedro Artigas <partigas at apple.com>

Hi Pedro (et al.), On 02/14/2013 11:43 PM, Pedro Artigas wrote: > I believe what is going on is that there is an issue with the way that information is deleted (the CG information). Yeap, that's exactly the problem! :-) I noticed that the GCModuleInfo::iterator (line 931 in lib/CodeGen/AsmPrinter/AsmPrinter.cpp) is empty and, thus, GCMetadataPrinter::finishAssembly is never called.

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

Ping for this. On 02/10/2013 08:47 PM, Yiannis Tsiouris wrote: > After rebasing my local LLVM repo to ToT, I noticed that the > finishAssembly function is not executed and, thus, the stack map is not > printed at all. > > Is this a known issue or I 'm doing something wrong? > > I used a custom GCMetadataPrinter plugin but I reproduced this using the > builtin

Hi, After rebasing my local LLVM repo to ToT, I noticed that the finishAssembly function is not executed and, thus, the stack map is not printed at all. Is this a known issue or I 'm doing something wrong? I used a custom GCMetadataPrinter plugin but I reproduced this using the builtin "ocaml" GC plugin and the attached file (actually, any simple ll file that uses

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

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

Hi Chandler, On 17/12/12 13:47, Chandler Carruth wrote: > On Sun, Dec 16, 2012 at 7:23 AM, Duncan Sands <baldrick at free.fr > <mailto:baldrick at free.fr>> wrote: > > Hi Stephen, > > > On 13/12/12 18:58, Stephen McGruer wrote: > > I'm wondering if the documentation for LoopPass >

On Sun, Dec 16, 2012 at 7:23 AM, Duncan Sands <baldrick at free.fr> wrote: > 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<http://llvm.org/docs/WritingAnLLVMPass.html#LoopPass>) >> is misleading or >> incorrect (or

Hello again, First of all, thanks for all the answers =) they really helped a lot =D *Have you verified that some other pass is not adding the function declarations back in after your pass is executed (e.g., by using the -debug-pass=Executions argument 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

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

Hello All, I have two questions, one more of an implementation question, the other more a design question. First: I noticed that if one moves the FPPassManager::doInitialization(Module) call from FPPassManager::runOnModule to MPPassManager::runOnModule (which is the new location I am aiming for to avoid the need for a doInitialization/doFinalization outside of the run methods, as preferred by

Hello All, I have two questions, one more of an implementation question, the other more a design question. First: I noticed that if one moves the FPPassManager::doInitialization(Module) call from FPPassManager::runOnModule to MPPassManager::runOnModule (which is the new location I am aiming for to avoid the need for a doInitialization/doFinalization outside of the run methods, as preferred by

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

I assume you meant to ask for ports that *don’t* support floating point exceptions. To my knowledge, neither R600 nor NVPTX support floating point exceptions. —Owen > On Aug 8, 2014, at 2:41 PM, Eric Christopher <echristo at gmail.com> wrote: > > There's a lot of cut and paste in those routines. Can you do something > to unify it a bit? Also, do we have any ports 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

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