search for: unreachableblockelim

Dear LLVM, I'm trying to understand why opt tool does not know some of the registered passes, for example, -targetpassconfig, -gc-lowering, -unreachableblockelim, -unreachableblockelim, -stack-protector, -machinemoduleinfo. This prevents me from using bugpoint to reduce the crash in backend. As I understand, they should be registered and available through the command line in the same way as all other passes, shouldn't they? Thanks, - Dima.

...I would like to modify bugpoint to work on this end. Thanks, - D. 2012/6/29 Duncan Sands <baldrick at free.fr>: > Hi Dima, > >> I'm trying to understand why opt tool does not know some of the >> registered passes, for example, -targetpassconfig, -gc-lowering, >> -unreachableblockelim, -unreachableblockelim, -stack-protector, >> -machinemoduleinfo. This prevents me from using bugpoint to reduce the >> crash in backend. As I understand, they should be registered and >> available through the command line in the same way as all other >> passes, shouldn't...

Hi Dima, > I'm trying to understand why opt tool does not know some of the > registered passes, for example, -targetpassconfig, -gc-lowering, > -unreachableblockelim, -unreachableblockelim, -stack-protector, > -machinemoduleinfo. This prevents me from using bugpoint to reduce the > crash in backend. As I understand, they should be registered and > available through the command line in the same way as all other > passes, shouldn't they? these ar...

...this end. > > Thanks, > - D. > > 2012/6/29 Duncan Sands <baldrick at free.fr>: >> Hi Dima, >> >>> I'm trying to understand why opt tool does not know some of the >>> registered passes, for example, -targetpassconfig, -gc-lowering, >>> -unreachableblockelim, -unreachableblockelim, -stack-protector, >>> -machinemoduleinfo. This prevents me from using bugpoint to reduce the >>> crash in backend. As I understand, they should be registered and >>> available through the command line in the same way as all other >>> passe...

...m both ModulePass and ProfileInfo, and this pass requires the CallGraph, i.e., * class myPass : public ModulePass, public ProfileInfo { ...};* * void myPass::getAnalysisUsage(AnalysisUsage &AU) const {* * AU.addRequired<CallGraph>();* * AU.setPreservesAll();* *}* Then, I assumes the UnreachableBlockElim (inherited from FunctionPass) requires myPass, by revising the related function as follows: *UnreachableBlockElim::getAnalysisUsage(AnalysisUsage &AU) const { * * AU.addPreserved<DominatorTree>();* * AU.addPreserved<ProfileInfo>();* * AU.addRequired<StaticProfilePas...

...out->data[Z] = d->data[i * 3 + Z] * d->data[j * 3 + Z]; } } } I'm looking through the IR transformations during passes added by LLVMTargetMachine::addPassesToEmitFile and seeing something I could use some help explaining. The point of interest is between 'unreachableblockelim' and 'codegenprepare' passes. Here is the paste of IR after each pass http://pastebin.com/42xLT4ZN I've annotated 3 spots in the code with stars. In (1), after unreachableblockelim, addr89 is precomputed outside the loop once and is used in store in (2). However, in (3), afte...

...;> >> 2012/6/29 Duncan Sands <baldrick at free.fr>: >>> >>> Hi Dima, >>> >>>> I'm trying to understand why opt tool does not know some of the >>>> registered passes, for example, -targetpassconfig, -gc-lowering, >>>> -unreachableblockelim, -unreachableblockelim, -stack-protector, >>>> -machinemoduleinfo. This prevents me from using bugpoint to reduce the >>>> crash in backend. As I understand, they should be registered and >>>> available through the command line in the same way as all other >&g...

...ease build for the last 24 hours or so. This is on Ubuntu Jaunty on x86. Known problem? If not, does anyone have an easy recipe for getting the build system to tell me the command line that's being used and to leave a preprocessed file sitting around? Thanks, John llvm[2]: Compiling UnreachableBlockElim.cpp for Release build StrongPHIElimination.cpp: In member function '(anonymous namespace)::StrongPHIElimination::InsertCopies(llvm::DomTreeNodeBase<llvm::MachineBasicBlock>*, llvm::SmallPtrSet<llvm::MachineBasicBlock*, 16u>&)': StrongPHIElimination.cpp:1051:1: internal com...

...() nounwind { > entry: > ret i32 -1 > test_label: > br label %ret > ret: > ret i32 -1 > } > > The basic problem is that we codegen test1, which generates a reference to test_label, then we codegen test_func. The optimization passes that run before the code generator (UnreachableBlockElim & CodeGenPrepare) zap dead blocks, so test_label was being deleted. > > The code generator doesn't want dead blocks coming into it for various reasons, so removing them is important. I guess we'll have to do something like buffer up the unemitted labels and emit them at the end...

...est_fun, %test_label) } define i32 @test_fun() nounwind { entry: ret i32 -1 test_label: br label %ret ret: ret i32 -1 } The basic problem is that we codegen test1, which generates a reference to test_label, then we codegen test_func. The optimization passes that run before the code generator (UnreachableBlockElim & CodeGenPrepare) zap dead blocks, so test_label was being deleted. The code generator doesn't want dead blocks coming into it for various reasons, so removing them is important. I guess we'll have to do something like buffer up the unemitted labels and emit them at the end of the fil...

...m both ModulePass and ProfileInfo, and this pass requires the CallGraph, i.e., * class myPass : public ModulePass, public ProfileInfo { ...};* * void myPass::getAnalysisUsage(AnalysisUsage &AU) const {* * AU.addRequired<CallGraph>();* * AU.setPreservesAll();* *}* Then, I assumes the UnreachableBlockElim (inherited from FunctionPass) requires myPass, by revising the related function as follows: *UnreachableBlockElim::getAnalysisUsage(AnalysisUsage &AU) const { * * AU.addPreserved<DominatorTree>();* * AU.addPreserved<ProfileInfo>();* * AU.addRequired<StaticProfilePas...

...s are complete? > > Yes, I should think so. > > /jakob > > > Thank you very much for your talk. > I think I could append more information about updating LiveIntervals. > 1. It works well if I just use from step1 to step3, without step4. > 2. In step4, I firstly use UnreachableBlockElim pass to delete OldMBB. > Then, remove all intervals and recompute all the virtual registers' LiveIntervals. > 3. I debug source code in LiveRangeCalc.cpp and copy partial code shown following. > /// LiveRangeCalc.cpp > ... > #ifndef NDEBUG > if (MBB->pred_empty()) { &gt...

...This is on Ubuntu Jaunty on x86.  Known problem?  If not, does > anyone have an easy recipe for getting the build system to tell me the > command line that's being used and to leave a preprocessed file sitting > around? > > Thanks, > > John > > > llvm[2]: Compiling UnreachableBlockElim.cpp for Release build > StrongPHIElimination.cpp: In member function '(anonymous > namespace)::StrongPHIElimination::InsertCopies(llvm::DomTreeNodeBase<llvm::MachineBasicBlock>*, > llvm::SmallPtrSet<llvm::MachineBasicBlock*, 16u>&)': > StrongPHIElimination.cpp:10...

....bc -debug-pass=Arguments and got Pass Arguments: -targetdata -targetpassconfig -no-aa -tbaa -targetlibinfo -basicaa -collector-metadata -machinemoduleinfo -machine-branch-prob -preverify -domtree -verify -loops -loop-simplify -scalar-evolution -loop-simplify -iv-users -loop-reduce -gc-lowering -unreachableblockelim -codegenprepare -stack-protector -preverify -domtree -verify -loops -branch-prob -expand-isel-pseudos -tailduplication -opt-phis -localstackalloc -dead-mi-elimination -machinedomtree -machine-loops -machinelicm -machine-cse -machine-sink -peephole-opts -unreachable-mbb-elimination -livevars -phi-no...

...really > isn't being run. The verifier can be hidden by various levels of > abstraction. Assuming that I get everything with -debug-pass=Structure, then it isn't: % llc -march=x86 -stats -f tests/IS/npbis.bc -debug-pass=Structure Pass Arguments: -lowergc -lowerinvoke -lowerswitch -unreachableblockelim Target Data Layout Module Pass Manager Function Pass Manager Lower GC intrinsics, for GCless code generators -- Lower GC intrinsics, for GCless code generators Lower invoke and unwind, for unwindless code generators -- Lower invoke and unwind, for unwindless code generators Lower Sw...

Hi, i ran into a problem when using blockaddress() with a label in another function. It seems to me that LLVM tries to remove the label used in blockaddress because it seems like it is not used, but in fact it may be used somewhere with a indirectbr. I attached a small test-case that produces this error. (The original problem is much more complicated, so i hope the reduced example, which has no

On Dec 7, 2007, at 1:43 AM, Wojciech Matyjewicz wrote: > Recently, I was looking into the bug #1227. I wanted to check if > reordering optimization passes could solve it. To start with, I > tried to > reproduce the output of llvm-g++ -O3 using the combination of llvm-g++ > -O0 and opt with the appropriate passes. However, I was unable to. I > use > SVN versions of llvm and

On Jan 3, 2014, at 1:52 PM, Andrew Trick <atrick at apple.com> wrote: > He really just wants to rerun LiveIntervals analysis, but LiveVariables is no longer available. Would it work just to clear all the intervals rerun LiveIntervals::computeVirtRegs after all the CFG transforms are complete? Yes, I should think so. /jakob -------------- next part -------------- An HTML attachment was

...o -jump-instr-table-info -targetpassconfig -no-aa -tbaa -scoped-noalias -assumption-tracker -basicaa -collector-metadata -machinemoduleinfo -machine-branch-prob -jump-instr-tables -atomic-expand -verify -verify-di -domtree -loops -loop-simplify -scalar-evolution -iv-users -loop-reduce -gc-lowering -unreachableblockelim -consthoist -partially-inline-libcalls -codegenprepare -rewrite-symbols -verify-di -stack-protector -verify -domtree -loops -branch-prob -machinedomtree -expand-isel-pseudos -tailduplication -opt-phis -machinedomtree -slotindexes -stack-coloring -localstackalloc -dead-mi-elimination -machinedomtree...

...t; ret i32 -1 >> test_label: >> br label %ret >> ret: >> ret i32 -1 >> } >> >> The basic problem is that we codegen test1, which generates a reference to test_label, then we codegen test_func. The optimization passes that run before the code generator (UnreachableBlockElim & CodeGenPrepare) zap dead blocks, so test_label was being deleted. >> >> The code generator doesn't want dead blocks coming into it for various reasons, so removing them is important. I guess we'll have to do something like buffer up the unemitted labels and emit them at...