search for: pruneeh

Hi, Simple description of the problem below. I have code coming into pruneEH as follows fn a { entry: call fn b ... for_cond: %i = phi [1, entry] [%x, for_body] cmp $i with someval cond-br for_body or for_exit for_body: ... $x = $i + 1 branch for_cond for_exit ... } PruneEH determines that the call to fn-b won't return. The code is modified thus. fn a { entry: call...

...he following C source: extern unsigned int donut; void f1(); void f2(); void f1() { unsigned int *magic = &donut; if (*magic != 286529877) { f2(); } } void f2() { /* Loop here forever if application is built with wrong version of ROM image */ while(1) { ; } } The -O2 level PruneEH pass uses SimplifyFunction() which contains this code: for (BasicBlock::iterator I = BB->begin(), E = BB->end(); I != E; ) if (CallInst *CI = dyn_cast<CallInst>(I++)) if (CI->doesNotReturn() && !CI->isMustTailCall() && !isa<Unreach...

...Trace()+0x1a)[0x84eb812] gccld((anonymous namespace)::SignalHandler(int)+0x110)[0x84ebb3a] [0xffffe420] /lib/libc.so.6(abort+0x103)[0x9226e3] /lib/libc.so.6(__assert_fail+0xfd)[0x91aabd] gccld(llvm::CallGraphNode::removeCallEdgeTo(llvm::CallGraphNode*)+0x41)[0x83c1ac d] gccld((anonymous namespace)::PruneEH::DeleteBasicBlock(llvm::BasicBlock*)+0x175) [0x838c82f] gccld((anonymous namespace)::PruneEH::SimplifyFunction(llvm::Function*)+0x2cf)[0 x838cc55] gccld((anonymous namespace)::PruneEH::runOnSCC(std::vector<llvm::CallGraphNode*, std::allocator<llvm::CallGraphNode*> > const&)+0x6e)[0x...

...x100)[0x848363c]<br> /lib/tls/libc.so.6[0xbe7a48]<br> /lib/tls/libc.so.6(abort+0x129)[0xbe9319]<br> /lib/tls/libc.so.6(__assert_fail+0x101)[0xbe0f41]<br> gccld(llvm::CallGraphNode::removeCallEdgeTo(llvm::CallGraphNode*)+0x3d)[0x837697f]<br> gccld((anonymous namespace)::PruneEH::DeleteBasicBlock(llvm::BasicBlock*)+0x16f)[0x8348265]<br> gccld((anonymous namespace)::PruneEH::SimplifyFunction(llvm::Function*)+0x2d4)[0x8347eee]<br> gccld((anonymous namespace)::PruneEH::runOnSCC(std::vector<llvm::CallGraphNode*, std::allocator<llvm::CallGraphNode*> > co...

...CallGraphSCCPass { >>> lib/Transforms/IPO/ArgumentPromotion.cpp: struct ArgPromotion : public >>> CallGraphSCCPass { >>> lib/Transforms/IPO/FunctionAttrs.cpp:struct >>> PostOrderFunctionAttrsLegacyPass : public CallGraphSCCPass { >>> lib/Transforms/IPO/PruneEH.cpp: struct PruneEH : public >>> CallGraphSCCPass { >>> lib/Analysis/CallGraphSCCPass.cpp: class PrintCallGraphPass : public >>> CallGraphSCCPass { >>> tools/opt/PassPrinters.cpp:struct CallGraphSCCPassPrinter : public >>> CallGraphSCCPass { >>&g...

...ind unwind label %lpad121 Something thinks that this invoke will always take the unwind path, which isn't the case, and marks the Unwind block as unreachable. As a consequence of that, the call to _Unwind_SjLj_Resume() is optimized away, and thus the function is considered to not throw in PruneEH.cpp. Very strange stuff. Thoughts on how to proceed in figuring out the root cause of what's going wrong? bool ShouldThrow; int throws() try { if (ShouldThrow) throw 7; return 123; } catch (...) { printf("'throws' threw an exception: rethrowing!\n"); throw;...

...ers dereferenceable - influences speculation safety, this primarily drives LICM, but can also effect things like PRE -- probably best to implement as a deref_or_nuill analysis and then merge nonnull inference to promote dereferenceable_or_null - see previous nounwind - currently implemented in PruneEH, missing in new pass manager -- this one will get fixed in the near future *Untrusted Declarations* In several cases, we check hasExactDefinition before checking properties of the function declaration (such as return type).  To my knowledge, facts on declarations are valid even in the place of...

...rs dereferenceable - influences speculation safety, this primarily drives LICM, but can also effect things like PRE -- probably best to implement as a deref_or_nuill analysis and then merge nonnull inference to promote dereferenceable_or_null - see previous nounwind - currently implemented in PruneEH, missing in new pass manager -- this one will get fixed in the near future Other cases I just noticed... noreturn -- useful for exception throw wrappers allocsize -- useful for allocation wrappers writeonly -- useful for AA speculatable - useful for speculation, LICM, PRE, etc... Untrusted De...

...primarily drives LICM, >> but can also effect things like PRE -- probably best to implement as a >> deref_or_nuill analysis and then merge nonnull inference to promote >> >> >> dereferenceable_or_null - see previous >> >> nounwind - currently implemented in PruneEH, missing in new pass manager -- >> this one will get fixed in the near future >> >> Other cases I just noticed... >> noreturn -- useful for exception throw wrappers >> allocsize -- useful for allocation wrappers >> writeonly -- useful for AA >> speculatable...

...speculation safety, this primarily drives > LICM, but can also effect things like PRE -- probably best to > implement as a deref_or_nuill analysis and then merge nonnull > inference to promote > > dereferenceable_or_null - see previous > > nounwind - currently implemented in PruneEH, missing in new pass > manager -- this one will get fixed in the near future > Other cases I just noticed... noreturn -- useful for exception throw wrappers allocsize -- useful for allocation wrappers writeonly -- useful for AA speculatable - useful for speculation, LICM, PRE, etc... > *...

...el %lpad121 > Something thinks that this invoke will always take the unwind path, > which isn't the case, and marks the Unwind block as unreachable. As a > consequence of that, the call to _Unwind_SjLj_Resume() is optimized > away, and thus the function is considered to not throw in PruneEH.cpp. > Very strange stuff. > > Thoughts on how to proceed in figuring out the root cause of what's > going wrong? > > > bool ShouldThrow; > > int throws() > try > { > if (ShouldThrow) throw 7; return 123; > } catch (...) { > printf("'thro...

...es speculation safety, this primarily drives LICM, > but can also effect things like PRE -- probably best to implement as a > deref_or_nuill analysis and then merge nonnull inference to promote > > > dereferenceable_or_null - see previous > > nounwind - currently implemented in PruneEH, missing in new pass manager -- > this one will get fixed in the near future > > Other cases I just noticed... > noreturn -- useful for exception throw wrappers > allocsize -- useful for allocation wrappers > writeonly -- useful for AA > speculatable - useful for speculation, L...

...its > caller/ancestor nodes need to be revisited in the next iteration. > Your proposal certainly sounds simpler and easier to reason about. (e.g. it naturally avoids any issues with deletion) Since there are only 3 non-inliner CGSCC passes (ArgPromotion, PostOrderFunctionAttrsLegacyPass, PruneEH) it may be feasible to remove the entire abstraction from LLVM and replace it with a cached post-order function pass visitation like you suggest. The inliner doesn't seem to do anything special with the knowledge that it is visiting an SCC (besides moving call sites that call within the SCC to...

...drives >> LICM, >> but can also effect things like PRE -- probably best to implement as a >> deref_or_nuill analysis and then merge nonnull inference to promote >> >> >> dereferenceable_or_null - see previous >> >> nounwind - currently implemented in PruneEH, missing in new pass >> manager -- >> this one will get fixed in the near future >> >> Other cases I just noticed... >> noreturn -- useful for exception throw wrappers >> allocsize -- useful for allocation wrappers >> writeonly -- useful for AA >> sp...

...gt;> but can also effect things like PRE -- probably best to implement as a >>> deref_or_nuill analysis and then merge nonnull inference to promote >>> >>> >>> dereferenceable_or_null - see previous >>> >>> nounwind - currently implemented in PruneEH, missing in new pass >>> manager -- >>> this one will get fixed in the near future >>> >>> Other cases I just noticed... >>> noreturn -- useful for exception throw wrappers >>> allocsize -- useful for allocation wrappers >>> writeonly...

...next iteration. >>> >> >> Your proposal certainly sounds simpler and easier to reason about. (e.g. >> it naturally avoids any issues with deletion) >> >> Since there are only 3 non-inliner CGSCC passes (ArgPromotion, >> PostOrderFunctionAttrsLegacyPass, PruneEH) it may be feasible to remove >> the entire abstraction from LLVM and replace it with a cached post-order >> function pass visitation like you suggest. The inliner doesn't seem to do >> anything special with the knowledge that it is visiting an SCC (besides >> moving cal...

I'd love to hear more details. Are you saying that this infinite loop is a limitation of EHABI table format, and not something that can be fixed in the compiler? Meanwhile, please notice that gcc behavior matches current clang behavior that I described above. We would not want to create an incompatibility. On Fri, Feb 14, 2014 at 8:42 PM, Logan Chien <tzuhsiang.chien at gmail.com>

...Attribute Properties -------------------- In this section, I would like to discuss the properties of no-unwind and no-throw, and the rules to infer the attributes if the programmer didn't specified them in function definition. These properties may be used by some optimization passes, such as PruneEH. First, since no-unwind implies no-throw, we can add no-throw attribute to the functions which have no-unwind attribute. Second, it is clear that the external functions should be considered as may-throw unless it is explicitly tagged with no-throw. Similarly, the external functions should be may-...

...would be explicitly documented, so then it wouldn't be implicit! In fact it would mean that "invoke" has the traditional LLVM semantics: if an exception is unwound then control branches to the landing pad. With the new scheme that is currently no longer so - meaning that some of the PruneEH logic is currently wrong :) That said, I'm also a bit dubious about this "always has a cleanup" idea. And it requires an optimization to "cleanup" (yeah, a pun...sue me) the extraneous code we generate, which won't happen at -O0 (right?). The only effect of this op...

Hi Everyone, Can Someone tell me all the interprocedural optimizations that LLVM 2.1 supports. Thank You, Naineet Patel CSE IITB