similar to: [LLVMdev] Conflicting passes?

Hi, > On Wed, 3 May 2006, Domagoj D wrote: > > 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 passes with > > interdependencies by serializing them (for example in the order as they were > > added to the queue). > >

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 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

Hi, This seems like a llvm-tv bug, but couldn't submit it as llvm.org is down: llvm[2]: Compiling CFGGraphDrawer.cpp for Debug build In file included from CFGGraphDrawer.cpp:2: TVTreeItem.h: In member function `virtual std::string TVTreeModuleItem::getTitle()': TVTreeItem.h:66: error: conversion from `const wxChar*' to non-scalar type ` std::string' requested make[2]: ***

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

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 >

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 all, I spent several hours today trying to compile llvm-gcc4 from svn and llvm from cvs on amd64 linux. In the case anyone else decides to try the same, this could ease your pain: 1) check out llvm, llvm-gcc 2) create llvm-obj llvm-gcc-obj export LLVM_INSTAL=<install_dir> cd llvm-obj export LLVM_OBJ=`pwd` ../llvm/configure --prefix=$LLVM_INSTALL --enable-debug-runtime 4) At one point,

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: >

On Sep 29, 2006, at 2:05 PM, Domagoj Babic wrote: > > Check out scc_* iterators. Also note that the call graph > is not aware of the indirect calls, so you will need to write your > own CG implementation if you need to handle function pointers > soundly. > Chris, is this true? If so, it seems like a bad property for the CallGraphSCCPass framework. --Vikram

Hi all, On 11/28/06, Reid Spencer <rspencer at reidspencer.com> wrote: > * Venue: West Coast, USA. Probably either San Francisco Bay Area or > Seattle > * Time Frame: Post 2.0 release, summer 2007 > * Topics: Anything related to use or development of LLVM I'd vote for Seattle. The costs of organization should be lower than in the Bay Area. > * An indication of how

On Oct 2, 2007, at 1:03 AM, Domagoj Babic wrote: > Hi all, > > I have the same problem. My guess is that when a structure > is passed as a parameter, you cast it into an array for optimization > reasons (less parameters, less stack space). This is not an optimization. This behavior is to be ABI complaint when emitting code for your OS. That said, this is not a very good way to

Hi all, I have the same problem. My guess is that when a structure is passed as a parameter, you cast it into an array for optimization reasons (less parameters, less stack space). This is, certainly, a reasonable optimization, but makes inter-procedural static analysis more complex. Is there a way to disable it (my guess is that this should be doable by passing some parameter to llvm-gcc)? If

Hi, I've ran my static checker Calysto on openssh and found the following bug: Possible NULL-ptr deref (vc536): @/work/benchmarks/SOURCES/openssh-4.6p1/moduli.c:173 + ptr gtm returned from gmtime dereferenced without checking (gmtime can return NULL). There are probably more possible NULL-ptr dereferences, but Calysto currently does not check the usage of library functions (for instance, if

New version of Calysto reports a warning that looks like a bug to me: ------------------------------------------ Possible NULL-ptr deref (vc27053): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:1823 Bug: ?? Explanation: choose_dh (dh.c:111) calls fopen twice (@120). If the first call to fopen fails (returns NULL), but the second one succeeds, fgets (@129) is called with f==NULL.

Hi, Here's something I don't understand... How come that UNDEF can appear as a branch condition at all? I just can't think of any ways. If you write something like fun() { int x; if (x > 100) { ... } else { ... } } LLVM generates a boolean temporary that compares (uninitialized) value of x with 100. Second, if it already can appear, isn't that a bug that

On Fri, 29 Sep 2006, Vikram Adve wrote: > On Sep 29, 2006, at 2:05 PM, Domagoj Babic wrote: >> Check out scc_* iterators. Also note that the call graph >> is not aware of the indirect calls, so you will need to write your >> own CG implementation if you need to handle function pointers >> soundly. > Chris, is this true? If so, it seems like a bad property for the