similar to: [LLVMdev] Conflicting passes?

Hi all, Why are these two passes conflicting: UnifyFunctionExitNodes and LowerSwitch? AU.addRequired(LowerSwitchID) works, so does AU.addRequired<unifyFunctionExitNodes>(), but the two together don't... opt: PassManagerT.h:387: void llvm::PassManagerT<Trait>::markPassUsed(const llvm::PassInfo*, llvm::Pass*) [with Trait = llvm::MTraits]: Assertion `getAnalysisOrNullUp(P)

Hi, A number of transforms are actually independent, so here's a partial fix. I updated the dependencies in a cluster of transforms: LowerSwitch, Mem2Reg, LowerSelect, LowerAllocations, UnifyFunctionExitNodes. The patch has been tested, but not extensively. PassManager doesn't complain, and the result of a test pass that requires all these (except for LowerAllocations) together works

Hi, > On Tue, 2 May 2006, Domagoj D wrote: > > Why are these two passes conflicting: UnifyFunctionExitNodes and LowerSwitch? > > Because they invalidate each other. Neither preserves the other. > > -Chris I thought so. However, it's not clear to me why "preservation" is required at all? That's just an optimization. The PassManager should be able to run

On 2007-03-18, at 03:22, Lang Hames wrote: > Is there a recommended way to find the final block (the one with > successors={}) in a machine function? This isn't a property of the CFG in the general case. However, the UnifyFunctionExitNodes transformation/analysis provides it. From getAnalysis<UnifyFunctionExitNodes>().getReturnBlock(), you can visit the basic block

On Mar 30, 2010, at 7:51 PM, John Criswell wrote: > I'm too lazy to convert your .dot file into a graph file What format should I have posted? (I'm not sure what you mean by "graph file".) I had thought that .dot was the preferred format here, since that's what LLVM generates (e.g., "opt -dot-cfg ..."). > First, LLVM does not guarantee that a function

Now that we have a "-why" option to the GenLibDeps.pl utility (which is used by llvm-config to deduce library dependencies), a review of the output has led to a few dubious library dependencies. Here they are: All of the following dependencies are singletons (the dependent library depends on only a single symbol from the dependency library): libLLVMCodeGen.a:

Trevor Harmon wrote: > On Jul 22, 2010, at 2:05 PM, John Criswell wrote: > > >> If you write your pass as a ModulePass, then you can iterate over the >> functions in any order that you want. >> > > I had considered that, but my FunctionPass depends on other passes > processing the functions first: > Two things to consider: 1) The PassManager

John Criswell wrote: > Trevor Harmon wrote: >> On Jul 22, 2010, at 2:05 PM, John Criswell wrote: >> >> >>> If you write your pass as a ModulePass, then you can iterate over the >>> functions in any order that you want. >>> >> >> I had considered that, but my FunctionPass depends on other passes >> processing the functions first:

On Jul 22, 2010, at 2:05 PM, John Criswell wrote: > If you write your pass as a ModulePass, then you can iterate over the > functions in any order that you want. I had considered that, but my FunctionPass depends on other passes processing the functions first: void MyPass::getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<UnifyFunctionExitNodes>();

Hi, I've written a FunctionPass that happens to be read-only (preserving): It doesn't modify the code in any way; it just does some analysis and dumps out the results for each function by overriding FunctionPass::print. I now need to make some changes to the pass, and these changes will mean that the results cannot be known until all functions have been visited. So there's

On 8/29/07, Domagoj Babic <babic.domagoj at gmail.com> wrote: > Seung, > > On 8/25/07, Chris Lattner <sabre at nondot.org> wrote: > > Ok. Note that LLVM can represent irreducible loops. You can handle > > this through code duplication. > > -Chris > > > If you are willing to invest more effort into a more complicated analysis, > in many cases you

I have a ModulePass, which we'll call MP, that generates a dependency graph for an entire program. I want MP to require the UnifyFunctionExitNodes pass, which is a FunctionPass. Since its not possible to make a ModulePass depend on a FunctionPass, is my only choice to make MP a FunctionPass in which the runOnFunction() routine does nothing, and the doFinalization routine does all the

Hi Andrew, > This should really be in the FAQ. But sufice to say if you make > your pass a function pass, you will be fine. > Andrew Thx for you reply. I think I can squeeze everything into a function pass, but I'd like to run this by you, just in the case I mixed-up something: (Chris, I'd also appreciate you wise thoughts on this. I'm sure that other users are banging

Seung, On 8/25/07, Chris Lattner <sabre at nondot.org> wrote: > Ok. Note that LLVM can represent irreducible loops. You can handle > this through code duplication. > -Chris If you are willing to invest more effort into a more complicated analysis, in many cases you can even avoid code duplication. See this paper for details: @inproceedings{erosa94taming, author = {Ana M.

Daniel, On 8/30/07, Daniel Berlin <dberlin at dberlin.org> wrote: > On 8/29/07, Domagoj Babic <babic.domagoj at gmail.com> wrote: > > Seung, > > > > On 8/25/07, Chris Lattner <sabre at nondot.org> wrote: > > > Ok. Note that LLVM can represent irreducible loops. You can handle > > > this through code duplication. > > > -Chris >

On Wed, Mar 31, 2010 at 2:59 PM, Trevor Harmon <trevor.w.harmon at nasa.gov> wrote: > I'm wondering what would cause a CFG not to have a return block. The > comments in UnifyFunctionExitNodes.cpp say: "If there are no return > stmts in the Function, a null pointer is returned." But this doesn't > make sense; even an empty void function has a return block with a

Chandler/Domagoj, On Sun, 2006-12-10 at 10:53 -0500, Chandler Carruth wrote: > Unless I'm missing something, the problem lies directly with the fact > that you are trying to do a link-stage operation with the GCC > frontend. GCC, by default, probably runs "ld" or another system > linker, which grabs the executable from binutils. This linker hasn't > been modified

I am also trying to build llvm-gcc4 and llvm as you are on amd64 linux. I am currently running into the error "Did not get a target machine!" on the first file compiled by xgcc. Did you encounter this error at all? Also, what distribution did you use? GCC version, and target triple? Thanks, -Chandler Carruth On 12/10/06, Domagoj Babic <babic.domagoj at gmail.com> wrote: >

Unless I'm missing something, the problem lies directly with the fact that you are trying to do a link-stage operation with the GCC frontend. GCC, by default, probably runs "ld" or another system linker, which grabs the executable from binutils. This linker hasn't been modified (yet) to include support for .bc files, but you're compiler is emitting byte code to the *.o files.

Hi, I found an existing pass "CalledValuePropagation" that can solve the problem I raised a few days ago regarding the "callees" metadata ( https://groups.google.com/forum/#!topic/llvm-dev/yjtZVMH_aC4). Now I have difficulty in calling this pass in my own pass. In my own pass, I called "getAnalysis<CalledValuePropagationPass>()" and in the