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

Displaying 20 results from an estimated 50000 matches similar to: "[LLVMdev] Disable the Module Verifier pass?"

2010 Apr 20
0
[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
2010 Apr 20
1
[LLVMdev] Disable the Module Verifier pass?
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
2008 Apr 18
1
[LLVMdev] Disabling Verifier
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
2011 May 02
0
[LLVMdev] difficulty in replicating a sequence of instructions + inserting at a different location -- "instruction doesn't dominate all uses"
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
2011 May 02
3
[LLVMdev] difficulty in replicating a sequence of instructions + inserting at a different location -- "instruction doesn't dominate all uses"
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
2015 Aug 31
2
RFC: LTO should use -disable-llvm-verifier
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
2015 Aug 31
2
RFC: LTO should use -disable-llvm-verifier
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
2015 Aug 31
2
RFC: LTO should use -disable-llvm-verifier
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
2010 Apr 06
2
[LLVMdev] Get the loop trip count variable
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:
2016 Aug 02
3
LLVM bc converter from LLVM 3.9 to LLVM 3.1
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
2015 Aug 31
4
RFC: LTO should use -disable-llvm-verifier
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
2011 Jul 28
1
[LLVMdev] New Problem: llc -O0: Broken module found, compilation aborted!
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
2013 Dec 17
0
[LLVMdev] Debug Info Verifier: should we create a module pass for it?
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
2015 Sep 01
3
RFC: LTO should use -disable-llvm-verifier
> 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
2020 Aug 11
2
opt - replicating multiple passes from -O3 -debug-pass=Executions
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
2013 Dec 19
1
[LLVMdev] Debug Info Verifier: should we create a module pass for it?
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 >
2016 Aug 03
2
LLVM bc converter from LLVM 3.9 to LLVM 3.1
> > 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
2013 Nov 19
2
[LLVMdev] Debug Info Verifier: should we create a module pass for it?
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:
2017 Apr 26
2
Collectively dominance
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:
2017 Apr 26
1
Collectively dominance
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, > >