search for: intconst

...stant *filenmConst = new GlobalVariable(M, filenmInit->getType(), false, GlobalVariable::ExternalLinkage, filenmInit, ".filenm"); //create global variable for int Constant* intInit = ConstantInt::get(Type::getInt32Ty(M.getContext()), 10); Constant* intConst = new GlobalVariable(M, intInit->getType(), false, GlobalVariable::ExternalLinkage, intInit, ".int"); //create ConstantStruct for each hashtable entry Constant *dhashInit[] = {filenmConst, intConst}; Constant *dhashConst = ConstantStruct::get...

On Thu, Nov 26, 2009 at 2:31 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Hi Devang, > > Before I get to the contents of this particular patch, I have a higher-level > design question. Why is metadata stored off the LLVMContext? Why do we have FPConstants, IntConstants etc.. in LLVMContext ? :) > That seems like > the wrong place to me, this data is all specific to the particular module. > Specifically, a single MDNode may not cross modules, and if a module is > destroyed we should eliminate all the metadata that came with it. Metadata is not co...

https://bugzilla.samba.org/show_bug.cgi?id=10322 Summary: Slow Performance over Network rsync Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: Joerg.Grube at Gmx.De

Thank you very much. The code to initialize h1 to non-zero values was what I was looking for. It's almost working except for a type mismatch wrt dlist* llist field of h1. dlist static_lst[10] = { {1, 5, NULL}, ... }; dhash h1[10] = {{"myfile.txt", static_lst}, ... }; Along the lines of the code you had sent, I created a GlobalVariable* llist of type [10 x %struct.dlist]* for the

Hi Devang, Before I get to the contents of this particular patch, I have a higher-level design question. Why is metadata stored off the LLVMContext? That seems like the wrong place to me, this data is all specific to the particular module. Specifically, a single MDNode may not cross modules, and if a module is destroyed we should eliminate all the metadata that came with it. So, why

...26, 2009 at 2:31 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > > Hi Devang, > > > > Before I get to the contents of this particular patch, I have a > higher-level > > design question. Why is metadata stored off the LLVMContext? > > Why do we have FPConstants, IntConstants etc.. in LLVMContext ? :) > So you can build up Constants and Instructions before inserting them where they'll be used. I suppose that sounds reasonable to do for metadata too. > That seems like > > the wrong place to me, this data is all specific to the particular > modu...

Hi All, Now, in llvm trunk we support custom metadata, which can be attached with llvm instructions. One of the user is "debugging information". This user is special (not just because it is in llvm svn tree:) because whenever debug info is available, it is likely that corresponding metadata is attached with almost all instructions. In other words, usually it is all or nothing. This