similar to: [LLVMdev] Disable the Module Verifier pass?

Zheng Wang wrote: > Hello, > > Is there anyway to disable the module verifier pass (in llvm-ld and llc)? > > I got an error as " Instruction does not dominate all uses!". > Obviously, there must be something wrong. The module verifier simply > aborts `llvm-ld` instead of generating bytecode. If somehow I can > disable the module verifier, then I can use llc to

John Criswell wrote: > Zheng Wang wrote: >> Hello, >> >> Is there anyway to disable the module verifier pass (in llvm-ld and llc)? >> >> I got an error as " Instruction does not dominate all uses!". >> Obviously, there must be something wrong. The module verifier simply >> aborts `llvm-ld` instead of generating bytecode. If somehow I can

Hi, I've noticed that the funcionality in the Verifier.cpp significantely slows down the compilation, especially for big basic blocks. In this case the llvm::DominatorTree::dominates() seems to consume a lot of time. Some debugging has shown that it is the Assert2() macro usage in the Verifier::visitInstruction(), arount this place: // Definition must dominate use unless use is

On 5/2/11 11:59 AM, Chuck Zhao wrote: > I am having difficulty in replicating a sequence of instructions (2+, > with def-use dependencies within) and inserting them at a different > location. > > I have tried a few different approaches (IRBuilder, new Instruction(), > I->clone(), insertBefore/insertAfter,etc.), all leading to the same > error msg: > "Instruction

I am having difficulty in replicating a sequence of instructions (2+, with def-use dependencies within) and inserting them at a different location. I have tried a few different approaches (IRBuilder, new Instruction(), I->clone(), insertBefore/insertAfter,etc.), all leading to the same error msg: "Instruction doesn't dominate all uses" The DevList has a few previous

On Mon, Aug 31, 2015 at 9:53 AM, Rafael Espíndola <llvm-dev at lists.llvm.org> wrote: > Having it off by default makes sense to me. We just need an easy way of > enabling it from the clang driver. > Not sure I follow? Generally LTO inputs are going to be "user provided" (in the sense that they're not produced immediately prior by the same process - or you'd have

On Mon, Aug 31, 2015 at 11:44 AM, Duncan P. N. Exon Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On 2015-Aug-31, at 11:41, Eric Christopher <echristo at gmail.com> wrote: > > > > > > > > On Mon, Aug 31, 2015 at 11:40 AM Duncan P. N. Exon Smith via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > > On

On Mon, Aug 31, 2015 at 11:40 AM Duncan P. N. Exon Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On 2015-Aug-31, at 10:42, Reid Kleckner <rnk at google.com> wrote: > > > > On Mon, Aug 31, 2015 at 10:12 AM, Rafael Espíndola < > llvm-dev at lists.llvm.org> wrote: > > > > > Not sure I follow? Generally LTO inputs are going to

Thanks a lot for your guys' help!!! I guess once I am able to get *V* (which probably is a pointer to a Value object), then, I can instrument some code at the IR level to dump V. As long as I maintain V at this pass stage, I should be able to dump the loop trip count. This is true, isn't it? Basically, what I am going to do is to add a function call before the loop body, such as:

Hi mailing list, I has been working on a large project that is based on LLVM 3.1. Recently we are thinking to introduce an LLVM bc converter from LLVM 3.9 to LLVM 3.1, such that we can introduce some of the newest LLVM analyses and optimizations to our LLVM 3.1 based project. Have you worked on similar things that converting LLVM bc downward and has anything to share? Thanks Hongbin

On Mon, Aug 31, 2015 at 10:12 AM, Rafael Espíndola <llvm-dev at lists.llvm.org> wrote: > > > Not sure I follow? Generally LTO inputs are going to be "user provided" > (in the sense that they're not produced immediately prior by the same > process - or you'd have just produced a single Module in the first place, I > would imagine) so changing the default

Hi all, Here is my problem, overflow.c: int main() { return 0; } $ clang -c -fstack-protector-all overflow.c -emit-llvm overflow.bc $ llc -O0 overflow.bc The result seems like the Bug 9259 which had been fixed (r126812). But I find I still have the problem below: Both operands to a binary operator are not of the same type! %aaa = xor i8* %"Call Return Address", i32 1892499360

My off the cuff idea here is to make it a module pass, but we'll split the verification a bit: a) IR verification time - Verify debug metadata attached to instructions (i.e. line information). Only check it for structure (i.e. do the various metadata nodes have the right number and kind of operands). b) Module pass - Walk down from the CUs in the file and verify everything we see. I think

> On 2015-Aug-31, at 12:21, Eric Christopher <echristo at gmail.com> wrote: > Yep. This is where I was going :) Glad I found consensus, but I want to double-check that this makes sense to add to the driver. I didn't quite think through the implications myself. Since the driver doesn't know if there's any bitcode, or if LTO is going to be invoked, it seems like I'll

Hello, I am trying to replicate the output from opt -O3 foo.bc -o foo.opt.bc by specifying the individual passes instead of the -O3 flag. Looking at the passes from opt -O3 foo.bc -o foo.bc -debug-pass=Executions it seems there are two passes being run. When I run the flags indicated for the two passes specified in the 'Pass Arguments:' as two sequential opt processes or a single opt

On Mon, Dec 16, 2013 at 4:05 PM, Eric Christopher <echristo at gmail.com>wrote: > My off the cuff idea here is to make it a module pass, but we'll split the > verification a bit: > > a) IR verification time - > > Verify debug metadata attached to instructions (i.e. line information). > Only check it for structure (i.e. do the various metadata nodes have the >

> > I also have a look at the code, looks like it directly parse the bitcode > and build in memory representation in a different LLVM version than the > bitcode. Is this correct? According to your description, I guess the BitCodeWriter should be the one > to do the bitcode version downgrade, right? I think so. I don't know much about it and don't want to give you

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:

Hi Daniel, Thanks a lot for all these explanation, I will try it out. Hongbin On Tue, Apr 25, 2017 at 7:04 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Tue, Apr 25, 2017 at 6:42 PM, Hongbin Zheng <etherzhhb at gmail.com> > wrote: > >> >> >> On Tue, Apr 25, 2017 at 6:32 PM, Daniel Berlin <dberlin at dberlin.org> >> wrote:

Like I said, i'm nearly positive there is a much faster way, as the sets are mostly shared except in the cyclic case, and in all reducible cyclic cases, removal of back-arcs does not affect dominance (because in any reducible flowgraph, v dominates u whenever u,v is a back-arc) On Tue, Apr 25, 2017 at 7:38 PM, Hongbin Zheng <etherzhhb at gmail.com> wrote: > Hi Daniel, > >