search for: functionlisttype

...FooFunction(M); M->print(std::cout); // Now we going to create JIT ExistingModuleProvider *MP = new ExistingModuleProvider(M); ExecutionEngine *EE = ExecutionEngine::create(MP, false); sys::DynamicLibrary::AddSymbol("bar", (void*) bar); llvm::Module::FunctionListType& funcList = MP->getModule()->getFunctionList(); for (llvm::Module::FunctionListType::iterator i = funcList.begin() ; i != funcList.end() ; ++i) { EE->getPointerToFunction(i); } EE->recompileAndRelinkFunction(pFooF); std::vector<GenericVa...

...gt;print(std::cout); > > // Now we going to create JIT > ExistingModuleProvider *MP = new ExistingModuleProvider(M); > ExecutionEngine *EE = ExecutionEngine::create(MP, false); > > sys::DynamicLibrary::AddSymbol("bar", (void*) bar); > llvm::Module::FunctionListType& funcList = MP->getModule()- > >getFunctionList(); > > for (llvm::Module::FunctionListType::iterator i = > funcList.begin() ; i != funcList.end() ; ++i) > { > EE->getPointerToFunction(i); > } > > EE->recompileAndRelinkFunction(pF...

...ppearance doesn't seem to be bad thing. Are there any technical issues with addition of ordering? I guess class Module and it's uses in parser (and linker) will be mostly affected. Currently Module stores different entities separately and concatenates all top level asm into single string. FunctionListType FunctionList; ///< The Functions in the module std::string GlobalScopeAsm; ///< Inline Asm at global scope. Are there any other issues? Regards, Sergey Y.

...unctionPassManager = new llvm::FunctionPassManager( module.get() ); targetMachine->addPassesToEmitFile( *functionPassManager, llvm::fouts(), llvm::TargetMachine::CGFT_AssemblyFile, optLevel ); functionPassManager->doInitialization(); llvm::Module::FunctionListType &functionList = module->getFunctionList(); for ( llvm::Module::FunctionListType::iterator it=functionList.begin(); it!=functionList.end(); ++it ) functionPassManager->run( *it ); delete functionPassManager; It seems very bizarre to me that the back end can gener...

...FooFunction(M); M->print(std::cout); // Now we going to create JIT ExistingModuleProvider *MP = new ExistingModuleProvider(M); ExecutionEngine *EE = ExecutionEngine::create(MP, false); sys::DynamicLibrary::AddSymbol("bar", (void*) bar); llvm::Module::FunctionListType& funcList = MP->getModule()->getFunctionList(); for (llvm::Module::FunctionListType::iterator i = funcList.begin() ; i != funcList.end() ; ++i) { EE->getPointerToFunction(i); } EE->recompileAndRelinkFunction(pFooF); std::vector<GenericVa...

> Are there any reasons why option can't be supported by llvm? It is hard and has very few users. For this to work you would have to add ordering information to the LLVM IL. It looks easier to patch eglibc. > Regards, > Sergey Yakoushkin Cheers, -- Rafael Ávila de Espíndola

...be bad thing. > Are there any technical issues with addition of ordering? > I guess class Module and it's uses in parser (and linker) will be > mostly affected. > Currently Module stores different entities separately and concatenates > all top level asm into single string. >  FunctionListType FunctionList; ///< The Functions in the module >  std::string GlobalScopeAsm;    ///< Inline Asm at global scope. > > Are there any other issues? Take a look at gcc's implementation. They need to keep the order of every definition they see. It also has other issues: 1654 /* Ou...

Hi, llvm doesn't support -fno-toplevel-reorder option which affects glibc/eglibc for some targets. http://www.llvm.org/bugs/show_bug.cgi?id=6364 >From conversations with gcc and eglibc maintainers, seems option is highly expected and is not going to deprecate. >> 2010/2/23 Ian Lance Taylor <iant at google.com>: >> If option is going to deprecate in gcc in near future as