search for: libanalysi

...MachinePassRegistry >> - MachinePostDominators >> - MachineRegisterInfo >> - MachineSSAUpdater >> - MachineVerifier Thanks for whittling the list down, Andrew. One question that has been nagging at me since I started looking into this is what to do about the dependency on libAnalysis? Some of these classes (eg. MachineFunctionPass are MachineLoopInfo) seem to have a hard dependency on the Pass class in libAnalysis. Is it acceptable to carry this dependency along to the new library? Or should we be aiming to eliminate this dependency like we are with the one on libCodeGen? &gt...

Hello, I have an analysis pass and a target machine class, both in different dynamically loadable libraries (plugins). There is no problem to use the analysis pass (opt -load=libanalysis.dylib -barpass foo.bc), but is it possible to get data from the analysis pass (by getAnalysis) while using the backend? AFAIK it is only allowed to have one plugin argument for llc (like: llc -load=libbackend.dylib -march=foo bar.bc). Did I miss something? Is the only solution to put the an...

...p': >> opt.cpp:(.text+0x1e89): undefined reference to `llvm::createMyAnaPass()' >> >> >> Am I missing out something. > Have you modified the Makefile in tools/opt to link in the library > containing your pass? Your pass doesn't appear to be placed in > libAnalysis or libTransform, so you'll need to modify the opt Makefile > to link in whatever your library's name is. > > -- John T. > >> Please help me. >> >> thanks and regards, >> Ambika >> >> _______________________________________________ >> L...

Hi, I did the Pass ID workaround by providing Passes.h in the include/llvm/Machine. But the question which is holding me up is that, as Ken Dyck was kind enough to point out, what should be done to the dependency on libAnalysis? The Machine passes are not only dependent on Passes class but also on others such as the ConstantFolding.h. Is it a possible solution to break this dependency or carry this dependency to the Machine library as well? Regards, Nitish B. -- View this message in context: http://llvm.1065342.n5.na...

...uctors keyed to opt.cpp': > opt.cpp:(.text+0x1e89): undefined reference to `llvm::createMyAnaPass()' > > > Am I missing out something. > Have you modified the Makefile in tools/opt to link in the library containing your pass? Your pass doesn't appear to be placed in libAnalysis or libTransform, so you'll need to modify the opt Makefile to link in whatever your library's name is. -- John T. > Please help me. > > thanks and regards, > Ambika > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs...

Hi, I am trying to add a pass inn LLVM, and I actually want to add it in source code, not just directly into object code. For that I included the lines in my file MyAna.cpp (llvm-2.6/lib/ana/MyAna.cpp) char MyAna::ID = 0; static RegisterPass<MyAna> X("my-aa","My Analysis"); static RegisterAnalysisGroup<AliasAnalysis> Y(X); ModulePass *llvm::createMyAnaPass() {

...pp:(.text+0x1e89): undefined reference to `llvm::createMyAnaPass()' >>> >>> >>> Am I missing out something. >> Have you modified the Makefile in tools/opt to link in the library >> containing your pass? Your pass doesn't appear to be placed in >> libAnalysis or libTransform, so you'll need to modify the opt Makefile >> to link in whatever your library's name is. >> >> -- John T. >> >>> Please help me. >>> >>> thanks and regards, >>> Ambika >>> >>> ___________________...

On Sep 5, 2013, at 5:15 PM, Ken Dyck <kd at kendyck.com> wrote: > Hi, > > One of the long-standing code clean-up bugs in Bugzilla is to extract > the Machine* code from the CodeGen library into a separate one, on > which CodeGen depends ( > http://llvm.org/bugs/show_bug.cgi?id=1121). > > I'd like to start working on this. The general approach I'm planning

...reateMyAnaPass()' >>>> >>>> >>>> Am I missing out something. >>>> >>> Have you modified the Makefile in tools/opt to link in the library >>> containing your pass? Your pass doesn't appear to be placed in >>> libAnalysis or libTransform, so you'll need to modify the opt Makefile >>> to link in whatever your library's name is. >>> >>> -- John T. >>> >>> >>>> Please help me. >>>> >>>> thanks and regards, >>>>...

...alysis/ConstantFolding.h" PromoteMemoryToRegister.cpp:#include "llvm/Analysis/Dominators.h" PromoteMemoryToRegister.cpp:#include "llvm/Analysis/AliasSetTracker.h" Am I right in assuming that the goal here is to get libTransformUtils to depend on nothing in libTransforms or libAnalysis? If so, its going to take some significant code rearrangement. Perhaps a lib/Analysis/Utils is in order? Please advise. Reid. On Wed, 2006-03-22 at 08:13 -0800, Reid Spencer wrote: > Okay, the problem with this cycle is LoopSimplify. It is using > AliasAnalysis which is where that _ZN4ll...

Okay, the problem with this cycle is LoopSimplify. It is using AliasAnalysis which is where that _ZN4llvm11BasicAAStubEv symbol is coming from. It seems to me that LoopSimplify.cpp is in the wrong place. This file defines the LoopSimplify FunctionPass which doesn't seem to me to be a "transform util". I thought the purpose of "Transforms/Util" was to provide utilities

Hi, One of the long-standing code clean-up bugs in Bugzilla is to extract the Machine* code from the CodeGen library into a separate one, on which CodeGen depends ( http://llvm.org/bugs/show_bug.cgi?id=1121). I'd like to start working on this. The general approach I'm planning to take is: 1. Identify which code to move. 2. Eliminate all dependencies that the Machine code has on the

On Sep 11, 2009, at 4:47 PM, Chris Lattner wrote: > > On Sep 11, 2009, at 2:11 PM, Dan Gohman wrote: > > >> >> >> On Sep 11, 2009, at 9:57 AM, Chris Lattner wrote: >> >> >> >> >> >>> Devang's work on debug info prompted this, thoughts welcome: >>> >>>

On Sep 11, 2009, at 2:11 PM, Dan Gohman wrote: > > On Sep 11, 2009, at 9:57 AM, Chris Lattner wrote: > > >> Devang's work on debug info prompted this, thoughts welcome: >> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt > > The document mentions "instructions" a lot. We'll want to be able to > apply metadata to ConstantExprs as well at

On Thu, 26 Feb 2004, Reid Spencer wrote: > One of the things that I don't understand well about LLVM is what code > is in what object files or library archives. It would be very useful if > there was a map of the dependencies between the files (e.g. if you link > X.o you need Y.a and Z.o). Trying to figure out the link lines by trial > and error is a bit frustrating. No

Hi all, I am experiencing a problem managing the command line option of a set of passes in my LLVM project. Attached you find a toy project the triggers the problem. The project is made up of two passes: "AnalysisPass" and "TransformPass". "TransformPass" requires "AnalysisPass" and they both share a common integer command line option called

...> > Could someone please add this file to the LLVM docs directory so I can > > submit patches against it? BTW, here's some hints for it: libtransforms.a -> contains only the level raise pass libtarget.a -> contains code generator support for describing target architectures libanalysis.a -> intraprocedural analyses libipa.a -> interprocedural analyses libinstrument.a -> instrumentation (e.g. profiling) transformations libtransformutils.a -> common code shared by various xforms libregalloc.a -> sparc register allocator sched.o -> sparc instruction schedu...

One of the things that I don't understand well about LLVM is what code is in what object files or library archives. It would be very useful if there was a map of the dependencies between the files (e.g. if you link X.o you need Y.a and Z.o). Trying to figure out the link lines by trial and error is a bit frustrating. To assist myself with understanding this, I've started to write a

...e made. While this is useless for malloc elimination in the general case (you care whether the callee might call free() not just whether it makes a copy) in your case with no explicit frees I think it's probably equivalent. The API is in include/llvm/Analysis/CaptureTracking.h, and link to libAnalysis. > Now I can see why LLVM doesn't do this -- it would be unsafe in > general. In my language (and many other high-level garbage-collected > languages which don't generate free() calls), it would be useful, but > LLVM itself can't guarantee that it's safe. > >>...

OK thanks for the replies. Yes, I was planning to use a garbage collector. This is for a functional language, so there's no real way to determine when memory needs to be freed without one. > Firstly, the pointer has to not make it into any function call at all, since any function might in turn call free(). Then we need to do escape analysis as you pointed out, but that's not