similar to: Where is the time going? - update

I followed what you said and called verifyModule() with the AbortProcessAction option. verifyModule() returns false, but does not abort and does not print out any information about what caused the verification to fail. Chris Lattner wrote: > On Wed, 21 Feb 2007, Ryan M. Lefever wrote: >> I am writing an interprocedural compiler pass. Because the passneeds >> information from a

I also tried iterating through the functions of the module and calling verifyFunction(), which also returns false, but does not cause an abort or report anything to stderr about what caused the verification to fail. From the doxygen for verifyFunction() and verifyModule(), it seems like they both should print information to stderr if the verification fails and should abort opt if

I think I misread the doxygen. verifyFunction & verifyModule return false if no errors are detected. However, my question now becomes why does the code produced by my transform pass verification, but it causes an assertion failure in the byte reader when it (the code produced by my transform) is passed to another invocation of opt? Ryan M. Lefever wrote: > I also tried iterating

Hello, One of my Julia programs failed to execute with the following error, DICompileUnit not listed in llvm.dbg.cu !11 = distinct !DICompileUnit(language: DW_LANG_C89, file: !3, producer: "julia", isOptimized: true, runtimeVersion: 0,emissionKind: FullDebug, enums : !12) This was generated by verifyModule(*GPUModule,&(llvm::errs())From whithin PPCGCodeGeneration.cpp in Polly.

Hi Xiu, The Verifier pass runs a PreVerifier pass, which does not honour the action argument, and will always abort on a broken module, (Line 106, lib/VMCore/Verifier.cpp) Perhaps you should file a bug against this, to allow you to not abort if you so wish. Joey On 11 June 2012 09:41, Guowei Xu <myesis at gmail.com> wrote: > Hello everyone: > > I have a little question

On Thu, 2004-04-01 at 18:04, Misha Brukman wrote: > Perhaps another solution would be to throw an exception with the error > message? Perhaps, but that would violate the programming contract already in place. Right now LLVM and its users expect failed verifications to cause an abort(). I wouldn't want to unleash on LLVM the new semantics of now handling exceptions in every place the

On Sat, Mar 11, 2017, at 07:34 PM, David Blaikie via llvm-dev wrote: > On Sat, Mar 11, 2017 at 3:10 AM SANJAY SRIVALLABH SINGAPURAM via llvm-dev > < > llvm-dev at lists.llvm.org> wrote: > > > Hello, > > > > One of my Julia programs failed to execute with the following error, > > DICompileUnit not listed in llvm.dbg.cu > > !11 = distinct

On Thu, 1 Apr 2004, Reid Spencer wrote: > On Thu, 2004-04-01 at 18:04, Misha Brukman wrote: > > > Perhaps another solution would be to throw an exception with the error > > message? > > Perhaps, but that would violate the programming contract already in > place. Right now LLVM and its users expect failed verifications to cause > an abort(). I wouldn't want to

On Wed, 21 Feb 2007, Ryan M. Lefever wrote: > I am writing an interprocedural compiler pass. Because the passneeds > information from a FunctionPass, e.g., the post-dominance frontier > (PDF), and because a ModulePass is not permitted to require a > FunctionPass, I am forced to make my pass a FunctionPass and do majority > of its work in the doFinalization() method. ok > When

Hello everyone: I have a little question about the second argument *action* of verifyFunction. In docs: *Enumerator: * *AbortProcessAction* verifyModule will print to stderr and abort() *PrintMessageAction* verifyModule will print to stderr and return true *ReturnStatusAction* verifyModule will just return true But it still abort when I pass

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Sean Silva > Subject: Re: [LLVMdev] What would cause instructions to NOT make it into the module? > It is a pass that can be run like any other pass. See createVerifierPass(). You can also just call verifyModule() with the appropriate parameters; it's defined in

Mhm I see now, thanks for your explanation! Son Tuan Vu On Fri, Mar 16, 2018 at 10:58 PM, Vedant Kumar <vsk at apple.com> wrote: > > On Mar 16, 2018, at 2:30 PM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hi Vedant, > > Thank you for your reply. I think I can make this debugify-each mode, but > I guess this is reserved for your GSoC project ? > >

I am writing an interprocedural compiler pass. Because the passneeds information from a FunctionPass, e.g., the post-dominance frontier (PDF), and because a ModulePass is not permitted to require a FunctionPass, I am forced to make my pass a FunctionPass and do majority of its work in the doFinalization() method. When I run "opt -mypass -verify -o code2.bc code1.bc" I get no

Hello, Calling `replaceUsesOfWith` with a value in a different addrspace does not keep the addrspace of a GEP consistent. Is this known? Is this a bug or expected behaviour? Minimal counterexample link <https://gist.github.com/bollu/152ba5e1c20c03c7fc6d8c7b23ba828f> Reproduced here: #include <iostream> #include "llvm/ADT/APFloat.h" #include

> On Mar 16, 2018, at 2:30 PM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hi Vedant, > > Thank you for your reply. I think I can make this debugify-each mode, but I guess this is reserved for your GSoC project ? No, there's no reserved work. If you'd like to work on this I encourage you to do so. There's plenty of other work slated for the GSoC project.

Hi Vedant, Thank you for your reply. I think I can make this debugify-each mode, but I guess this is reserved for your GSoC project ? However, if I understand correctly, we do not want to take the output of the first check-debugify (I mean the .ll file with potentially all the WARNINGs and ERRORs after the first pass) as input for the second debugify. What we need is to take the fresh output of

Hi Vedant, I have tried to implement the fix you proposed, but it didn't work as expected. I created a new *Module* Pass Manager (not Function Pass Manager) and override the *add()* method like this: class DebugifyEachPassManager : public legacy::PassManager { public: void add(Pass *P) override { PassManager::add(createDebugifyPass()); PassManager::add(P);

Hello, > On Apr 26, 2018, at 6:44 AM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hi Vedant, > > I have tried to implement the fix you proposed, but it didn't work as expected. I created a new Module Pass Manager (not Function Pass Manager) and override the add() method like this: > > class DebugifyEachPassManager : public legacy::PassManager { >

Marcello Maggioni <marcello at codeplay.com> writes: > I'm getting a very strange behaviour while adding already created > instructions in batches into basicblocks instead of creating and > inserting them immediately. > > Because I need to insert instructions in a certain specific order > inside multiple different BBs I found it easy to use the IRBuilder to > create

Hi Vedant, Thanks for your reply. More comments inline. Son Tuan Vu On Fri, Apr 20, 2018 at 10:19 PM, Vedant Kumar <vsk at apple.com> wrote: > Hi, > > + Chandler, who has a lot more experience with our pass managers. > > On Apr 20, 2018, at 12:56 PM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > + Vedant: what do you think about the last point, since