search for: gbegin

...tly print the declarations, but that's scary). There's another issue I don't understand. The module consists of functions and constants. I'd expect that external function declarations are also constants, with appropriate type. However, it seems they are not included in [Module::gbegin(), Module::gend()], insteads, they a Function objects with isExternal set to true. To me this seems a bit confusing -- it would be clearer if there we plain functions with bodies and everything else were GlobalValue. Anyther question is about SymbolTable. Is it true that it's a mapping fro...

On Fri, 2004-06-18 at 10:13, Chris Lattner wrote: > Module::gbegin/gend iterate over the global variables, and ::begin/end > iterate over the functions, some of which may be prototypes. This confused Vladimir and I remember it confusing me when I was reviewing LLVM core a few months ago. Would it be worthwhile to consider naming these globals_begin/globals_e...

...is motivation. > > There's another issue I don't understand. The module consists of > > functions and constants. I'd expect that external function declarations > > are also constants, with appropriate type. However, it seems they are not > > included in [Module::gbegin(), Module::gend()], insteads, they a Function > > objects with isExternal set to true. > > Module::gbegin/gend iterate over the global variables, and ::begin/end > iterate over the functions, some of which may be prototypes. Function > prototypes aren't really any more "...

...to make future refactoring easier. > There's another issue I don't understand. The module consists of functions and > constants. I'd expect that external function declarations are also constants, > with appropriate type. However, it seems they are not included in > [Module::gbegin(), Module::gend()], insteads, they a Function objects with > isExternal set to true. Module::gbegin/gend iterate over the global variables, and ::begin/end iterate over the functions, some of which may be prototypes. Function prototypes aren't really any more "constant" than othe...

...ht-forward translation from the C code in ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > this case. sorry, I still don't understand the way you mentioned. Would you mind giving me a example? What I have tried is that I used the following code for(Module::ginterator gI=M->gbegin(), gE=M->gbegin; gI!=gE;++gI){ std::cout<< *gI<< gI->getName()<<gI->getInitializer(); } With *gI, I could get all string With gI->getName, I could get the global variable name. With gI->getInitializer(), I could get the init value for the GV. Next, what I wan...

...RegisterOpt<DecodeStr> X("DecodeStr", "Decode to visible string"); } bool DecodeStr::runOnFunction(Function &F){ get_randKey(F.getParent()); DecodeString(F.getParent()); return true; } void DecodeStr::get_randKey(Module *M){ for(Module::giterator gI=M->gbegin(),gE=M->gend();gI!=gE;++gI){ std::string GVname = gI->getName(); if(strcmp(GVname.c_str(),"Gvkey")==0){ randKey =(gI->getInitializer()); } } } void DecodeStr::DecodeString(Module *M){ std::cerr<<"filename "<<M->getModuleIdentifier()...

...xternal function's linkage now... for (Module::iterator I = M.begin(), E = M.end(); I != E; ++I) visitGlobalValue(*I); for (Module::giterator I = M.gbegin(), E = M.gend(); I != E; ++I) visitGlobalValue(*I); // If the module is broken, abort at this time. abortIfBroken(); return false; } The fun...

On Fri, 18 Jun 2004, Reid Spencer wrote: > On Fri, 2004-06-18 at 10:13, Chris Lattner wrote: > > > Module::gbegin/gend iterate over the global variables, and ::begin/end > > iterate over the functions, some of which may be prototypes. > > This confused Vladimir and I remember it confusing me when I was > reviewing LLVM core a few months ago. Would it be worthwhile to consider > naming these g...

sure, that's reasonable. I'll make the patch but later this weekend .. bigger fish to fry :) Reid. On Fri, 2004-06-18 at 22:44, Chris Lattner wrote: > On Fri, 18 Jun 2004, Reid Spencer wrote: > > On Fri, 2004-06-18 at 10:13, Chris Lattner wrote: > > > > > Module::gbegin/gend iterate over the global variables, and ::begin/end > > > iterate over the functions, some of which may be prototypes. > > > > This confused Vladimir and I remember it confusing me when I was > > reviewing LLVM core a few months ago. Would it be worthwhile to consider...

On Thu, 1 Apr 2004, Reid Spencer wrote: > On Thu, 2004-04-01 at 18:04, Misha Brukman wrote: > > > Perhaps another solution would be to throw an exception with the error > > message? > > Perhaps, but that would violate the programming contract already in > place. Right now LLVM and its users expect failed verifications to cause > an abort(). I wouldn't want to

On Thu, 17 Jun 2004, Vladimir Prus wrote: > > Hi, > here I am again with "why is this so" kind of a question. Among different > types of MachineOperand there are MO_ExternalSymbol and MO_GlobalAddress. > > For MO_GlobalAddress, we can get usefull information from the getGlobal() > method, which returns GlobalValue*. Wouldn'it it be better is >

Hi, here I am again with "why is this so" kind of a question. Among different types of MachineOperand there are MO_ExternalSymbol and MO_GlobalAddress. For MO_GlobalAddress, we can get usefull information from the getGlobal() method, which returns GlobalValue*. Wouldn'it it be better is MO_GlobalAddress be called MO_GlobalValue, for consistency? Second, MO_ExternalSymbol is used

On Thu, 2004-04-01 at 18:04, Misha Brukman wrote: > Perhaps another solution would be to throw an exception with the error > message? Perhaps, but that would violate the programming contract already in place. Right now LLVM and its users expect failed verifications to cause an abort(). I wouldn't want to unleash on LLVM the new semantics of now handling exceptions in every place the