similar to: Why does verifyFunction dislike this?

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

Hi, I'm Ryo Ota. I'm using LLVM 3.8.1. I have a quesion about inlining function in C++ API. I'd like to inline some functions in a module in the same way as `opt -inline` command. But my C++ code didn't work what I want to do. For example, by using `opt -inline` command,`main.ll` is converted into the `inlined.ll`(`opt` command worked what I want to do) [main.ll (Not inlined)]

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 Tue, Jun 12, 2012 at 10:11:01AM +0800, Michael.Kang wrote: > > > On Mon, Jun 11, 2012 at 5:44 PM, Joey Gouly <joel.gouly at gmail.com> wrote: > > 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) >

On Mon, Jun 11, 2012 at 5:44 PM, Joey Gouly <joel.gouly at gmail.com> wrote: > 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) > So the argument can not be used as described as the official document? I just want to make sure of that and

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, using the LLVM API, I've build one very simple function that adds two ConstantInts and returns the result. I noticed that, when I emit IR code, it is optimized to a simple "ret i16 42" when I add 40 and 2. I'd like to see the operations that are necessary to compute the result, though. Can I somehow disable this optimization in the pass, leading to more verbose IR code?

I'm trying to create a global variable initialized to zero, and return its value from a newly created function, in JIT context. I'm keeping all types as i32 for the moment, and I only have the one module object. This is the code I have for creating the global variable: const Type *type = Type::getInt32Ty(getGlobalContext()); // Constant *zerov = Constant::getNullValue(type); Constant

IRBuilder is a templated class, and one of the template arguments is the constant folder to use. By default it uses the ConstantFolder class which does target-independant constant folding. If you want to disable constant folding you can specify the NoFolder class instead, i.e. declare the builder as follows: IRBuilder<true, llvm::NoFolder> builder(body) On 26 Nov 2013, at 19:23, Daniel

What does this error mean? I'm getting it from an ExecutionEngine::runFunction() call. The function I'm passing it was run through verifyFunction() right before the runFunction() call. I can't seem to find anything that tells me what causes this, only specific (but seemingly unrelated to my problem) cases of it happening. -------------- next part -------------- An HTML attachment was

The fundamental problem here is that opt doesn’t use ExecutionEngine (because it has no need to), so trying to use ExecutionEngine (or any other bit of llvm that opt doesn’t use for that matter) in an opt plugin isn’t going to work. The solution I’d go with would be to build llvm with shared libraries (use –DBUILD_SHARED_LIBS=ON on the cmake command) then link the plugin against ExecutionEngine.

The title says it all. verifyFunction checks it (Verifier.cpp, line 728). Why can't BasicBlocks that serve as a function's entry point also have predecessors? What keeps a function from looping back to its beginning? Félix -------------- next part -------------- An HTML attachment was scrubbed... URL:

Fair enough. In that case, is there an elegant way to test whether a basic block already has a terminator instruction? (I can think of several ways to do it in the front-end, but all of them are fairly inelegant. The problem I'm trying to solve is things like 'a return instruction needs to be added to the end of a function, if and only if the programmer didn't already end the function

Ah! I didn't know about verifyFunction; it does indeed catch it, thanks! I'll leave that call in my code for all cases for the moment, should help identify problems like that. Is there a recommended way to avoid this problem when compiling a language that has an explicit and optional return statement? On Fri, Feb 5, 2010 at 5:25 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote:

Did your test include running llvm::verifyFunction(...) on the function in question? I guess I should test this, but I would have thought this would catch the issue. Garrison On Feb 5, 2010, at 12:13, Russell Wallace wrote: > Fair enough. In that case, is there an elegant way to test whether a > basic block already has a terminator instruction? > > (I can think of several ways to

Hi, I want to run the Mem2Reg pass on a function without using the the LLVM opt utility. I wrote some code, which I am not sure is correct: TS_ASSERT(!verifyFunction(*function)); // find the dominance frontier of the CFG DominanceFrontier DF; DF.runOnFunction(*function); // try to promote stack allocated variables PromoteMemToReg(function->getRegAllocas(), DF, *tgt_data);

I'm having speed problems with the SCSI card we're using to do tape backup. It seems to be functioning in 16 bit mode and the current thinking is that perhaps it's using a legacy driver instead of the correct one. The Adaptec site has a 'driver' for RHEL5 which I've downloaded and tried to install but it seems to have a problem installing on a CentOS-5 system. [root at

On Aug 15, 2010, at 1:06 PM, Alec Benzer wrote: > What does this error mean? I'm getting it from an ExecutionEngine::runFunction() call. The function I'm passing it was run through verifyFunction() right before the runFunction() call. I can't seem to find anything that tells me what causes this, only specific (but seemingly unrelated to my problem) cases of it happening. Which