search for: registeropt

...y. As long as pass initialization happens before parseCommandLine, usage should be consistent. > > Strawman: > > cl::optval<bool> MyOption; // Just the storage, no initialization. > > MyPass() { > // Only registers an option with the same optval once. > Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden, > cl::desc("Descriptive string..."), ); > } Given Chandler's upcoming work on the pass manager, should we assume that multithreaded passes are a future possibility. If so, would the above variable need to be static...

...think we can do a bit better and that it's not necessarily so complex, here's a draft of possible design : We could have something like this in a package to register options along with an optional validator, triggered on `options(..)` (or a new function). # similar to registerS3method() : registerOption("mypkg.my_option1") registerOption("mypkg.my_option2", function(x) stopifnot(is.numeric(x)) # maybe a `default` arg too to avoid the .onLoad() gymnastics and invisible NULL options * validation is a breaking change so we'd have an environment variable to opt in * validat...

...at it's not necessarily so complex, > here's a draft of possible design : > > We could have something like this in a package to register options along > with an optional validator, triggered on `options(..)` (or a new function). > > # similar to registerS3method() : > registerOption("mypkg.my_option1") > registerOption("mypkg.my_option2", function(x) stopifnot(is.numeric(x)) > # maybe a `default` arg too to avoid the .onLoad() gymnastics and invisible > NULL options > > * validation is a breaking change so we'd have an environment var...

Hi, I wrote a machinefunction pass to try to see what's going on. Does it mean that it is target machine dependent pass, like x86? However, after compile it, I found there wasnot command option I registered. I used regular way to do it like RegisterOpt <...> X("... ", "... "), but I cannot see the optimized option when I use opt -load ../../lib/Debug/libxxx.so --help. And from LLVM source code, I saw some passes use runOnMachineFunction(MachineFunction &MF), but there is no API like registerOpt. what does it mean? Th...

...s the singleton and provides visibility. As long as pass initialization happens before parseCommandLine, usage should be consistent. Strawman: cl::optval<bool> MyOption; // Just the storage, no initialization. MyPass() { // Only registers an option with the same optval once. Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden, cl::desc("Descriptive string..."), ); } -Andy

..., > > here's a draft of possible design : > > > > We could have something like this in a package to register options along > > with an optional validator, triggered on `options(..)` (or a new > function). > > > > # similar to registerS3method() : > > registerOption("mypkg.my_option1") > > registerOption("mypkg.my_option2", function(x) stopifnot(is.numeric(x)) > > # maybe a `default` arg too to avoid the .onLoad() gymnastics and > invisible > > NULL options > > > > * validation is a breaking change so we&...

...std::cerr << " calling run machine function.\n"; return false; } virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesAll(); } virtual const char *getPassName() const { return "run on machine function"; } }; RegisterOpt<MacFoo> Z("allocpty", "Register Allocation Prototype Pass"); struct FuncFoo : public FunctionPass { virtual bool runOnFunction(Function &F) { std::cerr << "Function name: " << F.getName() << "\n"; return false;...

...n Tue, 19 Oct 2004, Zhang Qiuyu wrote: > I wrote a machinefunction pass to try to see what's going on. Does it > mean that it is target machine dependent pass, like x86? However, after > compile it, I found there wasnot command option I registered. I used > regular way to do it like RegisterOpt <...> X("... ", "... "), but I > cannot see the optimized option when I use opt -load > ../../lib/Debug/libxxx.so --help. And from LLVM source code, I saw some > passes use runOnMachineFunction(MachineFunction &MF), but there is no > API like registerOpt. w...

For those working from LLVM CVS: I simplified the pass interface, eliminating the need for the RegisterOpt vs RegistierAnalysis distinction. If you're working on an out-of-tree pass, you should just use 'RegisterPass' instead of RegisterOpt or RegisterAnalysis. I've updated the "Writing an LLVM Pass" doc to reflect current best practice. -Chris -- http://nondot.org/sab...

...make first and then install? Please let me > know if > you have any more problems. You were right. Doing a proper "make ; make install" did the trick. After making necessary adjustments to my LLVM-app (due to disappearing of ConstantSInt and ConstantUInt, and replacement of RegisterOpt by RegisterPass), all its tests passed. Didn't check LLVM's test suite. Kind regards, Bram Adams GH-SEL, INTEC, Ghent University

> When building LLVM 1.9 on OSX 10.4.8, I get (after a while, see attachment): > > make[1]: *** No rule to make target `/path/to/llvm-build/Debug/bin/tblgen', > needed by `/path/to/llvm-build/lib/VMCore/Debug/Intrinsics.gen.tmp'. Stop. > make: *** [install] Error 1 > > when doing: > > $LLVM_SRC/configure --prefix=$LLVM_INSTALL --with-llvmgccdir=$LLVM_FRONT

...achine function.\n"; > return false; > } > virtual void getAnalysisUsage(AnalysisUsage &AU) const { > AU.setPreservesAll(); > } > virtual const char *getPassName() const { > return "run on machine function"; > } > }; > RegisterOpt<MacFoo> Z("allocpty", "Register Allocation Prototype Pass"); > > struct FuncFoo : public FunctionPass { > virtual bool runOnFunction(Function &F) { > std::cerr << "Function name: " << F.getName() << "\n"; >...

Test Cases: (attached) Iteration code: (...) typedef TarjanSCC_iterator<CallGraph*> MyTarjan; CallGraph& callGraph = getAnalysis<CallGraph>(); MyTarjan iter = tarj_begin(&callGraph); MyTarjan end = tarj_end(&callGraph); while(iter!=end) iter++; (...) if you take the time to print out the function each non-looping node iter traverses, it never reaches main...

Hi, I'm having a problem with opt. According to the "Writing an LLVM Pass" tutorial, all I have to do to get the Hello pass to work is: cd ${LLVM_HOME}/llvm/lib/Transforms/Hello gmake cd $MYTEST opt -load ${OBJ_ROOT}/lib/Release/libhello.so -hello < something.bc > /dev/null First (just as a friendly reminder), someone may want to go back and double check a bunch of

...s long as pass initialization happens before parseCommandLine, > usage should be consistent. > > Strawman: > > cl::optval<bool> MyOption; // Just the storage, no initialization. > > MyPass() { > // Only registers an option with the same optval once. > Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden, > cl::desc("Descriptive string..."), ); > } > > -Andy > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://...

..."; > else > std::cerr << " Indirect node\n"; > } > return false; > } > virtual void getAnalysisUsage(AnalysisUsage &AU) const { > AU.setPreservesAll(); > AU.addRequired<CallGraph>(); > }; > }; > RegisterOpt<Test> Z("test", "test"); > > > -------------------- Testcase ------------------------ > > #include <stdlib.h> > #include <stdio.h> > > //#define WORKS > > int * a_global; > > int a_predicate = 1; > int another_pred =...

> On Aug 19, 2014, at 1:32 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >>> * Nobs for which there is not a single right answer for all users. >>> There are very few of these currently and we expect it to remain like >>> that. These should not use cl::opt or static storage at all. They >>> should be an option passed to the

.... As long as pass initialization happens before parseCommandLine, usage should be consistent. > > Strawman: > > cl::optval<bool> MyOption; // Just the storage, no initialization. > > MyPass() { > // Only registers an option with the same optval once. > Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden, > cl::desc("Descriptive string..."), ); > } > > -Andy > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http:/...

...n happens before parseCommandLine, usage should be consistent. >> >> Strawman: >> >> cl::optval<bool> MyOption; // Just the storage, no initialization. >> >> MyPass() { >> // Only registers an option with the same optval once. >> Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden, >> cl::desc("Descriptive string..."), ); >> } >> >> -Andy >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://l...

...ong as pass initialization > happens before parseCommandLine, usage should be consistent. > > Strawman: > > cl::optval<bool> MyOption; // Just the storage, no initialization. > > MyPass() { > // Only registers an option with the same optval once. > Option cl::registerOpt(MyOption, cl::init(false), cl::Hidden, > cl::desc("Descriptive string..."), ); > } Sounds good to me. Will this make it safe again to use -backend-option in Clang? [Not saying that we *want* to do that, but that's a separate matter]. Regardless of the...