similar to: [LLVMdev] Aborting a pass

On Mar 1, 2010, at 11:04 AM, Trevor Harmon wrote: > What's the proper way to abort a pass if something goes wrong (e.g., > in the pass's constructor)? Do I simply call abort()? Calling abort() causes a stack dump to the console, which is good for serious errors, but overkill for most other types of error situations, such as a command-line parameter that the user forgot to add.

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

Hi, For me, getTripCount always returns null, even for trivial loops such as: void simple(int j) { for (int i = 0; i < 10; i++) { j++; } } Looking through the mailing list archive, it appears that getTripCount requires certain optimization passes to run first, but it's not clear which ones. There doesn't seem to be any documentation on this. Does anybody

On May 6, 2010, at 6:32 PM, ether zhhb wrote: > As the comment said: > /// The IndVarSimplify pass transforms loops to have a form that > this > /// function easily understands. > > you could try -indvars. After adding -indvars to the opt command, getTripCount still returns null. I suppose it's possible, depending on the scheduling of the pass manager, that

On Feb 9, 2010, at 11:13 AM, Trevor Harmon wrote: > Is there any information about these changes and why they were > necessary? I think I found it: http://nondot.org/~sabre/LLVMNotes/EmbeddedMetadata.txt Still looking for an API to access the metadata... Trevor

On Mar 22, 2010, at 9:53 PM, John Criswell wrote: > You can always use the LLVM project infrastructure (documented at > http://llvm.org/docs/Projects.html). Thanks for reminding me of that. I had actually started out with a project infrastructure, then switched to a pass implementation alone, not realizing I could combine the two. I've now reverted back to my old project,

On Feb 8, 2010, at 8:51 PM, Duncan Sands wrote: > this can be done using debug info. Check out > http://llvm.org/docs/SourceLevelDebugging.html Wow, that threw me for a loop. I'm using the 2.6 release, thinking I was up to date, but its debug output doesn't look anything like what's described in the above link. It appears to document the upcoming 2.7 version, which

LLVM has a relatively large number of proprietary replacements for standard C++ functions and classes. One of these is dyn_cast to replace dynamic_cast. The two calls appear to be semantically equivalent; the only difference that I can see is that dyn_cast reportedly works on classes that have no v-table [1]. Could someone please explain why I should use dyn_cast instead of dynamic_cast?

On Apr 5, 2010, at 7:10 PM, funceval wrote: > opt -load ../../../Release/lib/iel.so > <premain>: CommandLine Error: Argument 'inline-threshold' defined > more than once! > opt: CommandLine Error: Argument 'inline-threshold' defined more > than once! > Error opening '../../../Release/lib/iel.so': ../../../Release/lib/ > iel.so: undefined

Trevor Harmon <Trevor.W.Harmon at nasa.gov> writes: [snip] > Could someone > please explain why I should use dyn_cast instead of dynamic_cast? (I > thought all classes have v-tables...) Thanks, For reducing executable size, LLVM builds with RTTI disabled where possible.

Hi, I'm developing an LLVM pass and am running into code maintenance issues. Specifically, the "Writing an LLVM Pass" document assumes that the pass directory is placed somewhere in the LLVM source base (e.g. lib/Transforms), but this is a problem for me because: 1) Testing the pass against two different LLVM versions is difficult. For example, testing with the LLVM 2.6

On Feb 24, 2010, at 11:04 AM, Trevor Harmon wrote: > $ ./AutoRegen.sh > LLVM source root not found. > Enter full path to LLVM source:/Users/twharmon/Development/LLVM/src/ > llvm-trunk/llvm > Enter full path to LLVM objects (empty for same as source):/Users/ > twharmon/Development/LLVM/llvm/ Actually, I think this part is wrong. If I supply the same path as the source,

On Feb 25, 2010, at 2:28 PM, Trevor Harmon wrote: > I'm not sure how the other program can find the output, unless > of course the analyzer simply dumps the file to a hard-coded > location (/tmp?). Replying to myself again... After sifting through many of the existing transforms, I discovered that new command-line parameters can be added to opt simply by declaring them in the

Hi, Yeah I found that it is running LLVM's functions. The functions that are running are: main llvm.dbg.func.start llvm.dbg.stoppoint scanf llvm.dbg.region.end But I dont want all the functions to be called as I am using Dominator Trees and whenever I the statement DominatorTree &DT = getAnalysis<DominatorTree>(F); is encountered by functions other than main, it gives error.

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

On Nov 12, 2010, at 5:57 PM, Óscar Fuentes wrote: >> Could someone >> please explain why I should use dyn_cast instead of dynamic_cast? (I >> thought all classes have v-tables...) Thanks, > > For reducing executable size, LLVM builds with RTTI disabled where > possible. Right, but how does that relate to dyn_cast? I thought v-tables were present even when RTTI is not

On Wed, Oct 20, 2010 at 7:19 PM, Jim Grosbach <grosbach at apple.com> wrote: > > On Oct 20, 2010, at 5:16 PM, Trevor Harmon wrote: >> I'm writing a pass that does some static analysis on C code. A >> critical requirement of the pass is that it must preserve not only the >> correctness of the code but also its timing -- It cannot add or remove >> even one CPU

On Nov 2, 2010, at 11:08 PM, Nick Lewycky wrote: > The unittests/ directory contains C++ unit tests for arbitrary C++ > APIs > that don't fit the dejagnu model of running opt or llc over .ll files. Thanks for the tip. Attached is a patch+testcase that adds CallGraphNode::isRecursive to LLVM. Could someone with commit access please review and apply? Thanks, Trevor

Hi, I'm trying to learn all that I can about exception handling from the compiler's point of view. Although much has been written about compiler theory in general -- parsing, code generation, you name it -- I can find almost nothing on the specific problem of exception handling support. In fact, the most informative document I've been able to find so far is "Bill's

On Mar 25, 2010, at 5:23 PM, me22 wrote: > Given that LLVM is already managing the memory and presumably will do > so for the life of your graph processing, could you just use a > boost::directed_graph<llvm::BasicBlock*> instead? Yeah, that was one of the first things I tried: for (Function::iterator i = function.begin(), e = function.end(); i != e; ++i) { BasicBlock