search for: createretvoid

...ilder(first_block); for (ValueSymbolTable::iterator vst_it = vst->begin(); vst_it != vst->end(); vst_it++) { AllocaInst* store_var = builder.CreateAlloca(type, 0,my_name.c_str()); builder.CreateStore(symbol, store_var, true); } //Put a terminator on the block builder.CreateRetVoid(); This builds fine, but I get dominator issues when I try to test it with opt. I'm sure that I just don't understand all of the constraints on the IR, but I would appreciate it if anyone can point me in the right direction. The output from opt is below. Instruction does not dominate...

...m::Function>(c); dummy->setLinkage(llvm::Function::ExternalLinkage); dummy->setCallingConv(llvm::CallingConv::C); llvm::BasicBlock* block = llvm::BasicBlock::Create("entry", dummy); // no context needed llvm::IRBuilder builder(block); // no need in <> builder.CreateRetVoid(); Cheers, Oleg. 2009/11/5 Renato Golin <rengolin at systemcall.org>: > 2009/11/5 Oleg Knut <oleg77 at gmail.com>: >> Hello, >> I have a simple question. How to create "dummy" function which will >> have no functionality behind (return nothing and do not...

...builder.CreateAlloca(builder.getDoubleTy(), a, "a"); 29 30 Value *c1 = ConstantFP::get(context, APFloat(1.0)); 31 Value *c2 = ConstantFP::get(context, APFloat(3.0)); 32 builder.CreateFAdd(c1, c2, "addtmp"); 33 34 builder.CreateCall(putsFunc, helloWorld); 35 builder.CreateRetVoid(); 36 module->dump(); 37 return 0; 38 } Produces: ; ModuleID = 'calc' @0 = private unnamed_addr constant [14 x i8] c"hello world!\0A\00" define void @main() { entrypoint: %a = alloca double %0 = call i32 @puts(i8* getelementptr inbounds ([14 x i8]* @0, i32 0, i32 0))...

...mmy->setLinkage(llvm::Function::ExternalLinkage); > dummy->setCallingConv(llvm::CallingConv::C); > llvm::BasicBlock* block = llvm::BasicBlock::Create("entry", dummy); > // no context needed > llvm::IRBuilder builder(block); // no need in <> > builder.CreateRetVoid(); > > Cheers, > Oleg. > > 2009/11/5 Renato Golin <rengolin at systemcall.org>: >> 2009/11/5 Oleg Knut <oleg77 at gmail.com>: >>> Hello, >>> I have a simple question. How to create "dummy" function which will >>> have no functi...

...ameters) { // add any additional parameters of the machine instruction to the function call llvm_arg++ = param; } // add the call to the function we're creating llvm_builder.CreateCall(machine_instr, llvm_arg); } // finish the function by adding return llvm_builder.CreateRetVoid(); // and finish with generating the function and saving it for later use llvm_function_pass_manager->run(*llvm_function); jit_functions[predicate_id] = (void*)(llvm_execution_engine->getPointerToFunction(llvm_function)); -----------------------------------------------------------------------...

Hello Duncan, There is a discussion with Chris Lattner: http://old.nabble.com/Eliminating-the-'void'-type-td33726468.html In the discussion, Chris Lattner suggest Type::getVoidTy() should still exist and return {} for API continuity. If VoidTy and isVoidTy() go away, how do deal with the isVoidTy() function call in LLVM source tree? Another issue is: What should ReturnInst constructor

2009/11/5 Oleg Knut <oleg77 at gmail.com>: > Hello, > I have a simple question. How to create "dummy" function which will > have no functionality behind (return nothing and do nothing)? > Currently I'm trying to do this: > > llvm::Constant* c = Module.getOrInsertFunction("dummy", > FunctionThatNeedsToBeReplaced.getFunctionType()); >

Hello, I have a simple question. How to create "dummy" function which will have no functionality behind (return nothing and do nothing)? Currently I'm trying to do this: llvm::Constant* c = Module.getOrInsertFunction("dummy", FunctionThatNeedsToBeReplaced.getFunctionType()); llvm::Function* dummy = llvm::cast<llvm::Function>(c); This way I create new function that

...enced in the exit_blk is created by: > BasicBlock *const unwind_resume_blk = BasicBlock::Create( ctx, "unwind_resume", fn ); > builder.SetInsertPoint( unwind_resume_blk ); > builder.CreateResume( builder.CreateLoad( caught_result_storage_ ); and the return_blk is simply a CreateRetVoid(). This all seems to work just fine. I can throw a C++ exception either in a C++ object's constructor or in an ordinary member function and the stack unwinds correctly (the object's destructors are called) and the exception is propagated back up the C++ code that called the JIT'd code...

...dule, Intrinsic::x86_sse_rcp_ps); Value *in = builder->Insert(new LoadInst(in_arg, "", false, 1)); Value *out = builder->CreateCall(rcpps, in); builder->Insert(new StoreInst(out, out_arg, false, 1)); builder->CreateRetVoid(); } delete builder; return function; } int main(int argc, char **argv) { Module *module = new Module("test"); Function *function = createFunction(module); ExistingModuleProvider *moduleProvider = new ExistingModuleProvider(module);...

...:Create(TypeBuilder<void(void), false>::get(Context), + Function::ExternalLinkage, + "func1", M); + BasicBlock *Block = BasicBlock::Create(Context, "block", F); + IRBuilder<> Builder(Block); + Builder.CreateRetVoid(); + TheJIT->getPointerToFunction(F); + ASSERT_TRUE(RJMM->startExceptionTableCalls.size() == 2); + ASSERT_TRUE(RJMM->deallocateExceptionTableCalls.size() == 1); + ASSERT_TRUE(RJMM->endExceptionTableCalls.size() == 1); +} + int PlusOne(int arg) { return arg + 1; } Index: lib/Exe...

Hi Dan, >> I am willing to do "eliminating the void type" project. > > Is this really a good idea? I'm not going to argue at length > about it, but it is worth thinking about. > > The only practical downsides of void are when newcomers take C's > syntax for functions with no arguments a little too literally, or > when they try to create pointers to

On Mar 23, 2012, at 4:29 PM, Paul J. Lucas wrote: > On Mar 23, 2012, at 3:25 PM, Bill Wendling wrote: > >> Let's take your example. You will have code that looks like this: >> >> extern "C" void thunk_item_M_delete( void *v_that ) { >> item *that = 0; >> try { >> that = static_cast<item*>( v_that ); >>

On Aug 21, 2012, at 2:12 PM, Michael Muller <mmuller at enduden.com> wrote: > > Hi, I found a bug in the code that generates exception tables, I've attached > what I think is the correct fix. > > When you run out of space writing to a buffer, the buffer management code > simply stops writing at the end of the buffer. It is the responsibility of > the caller to

Eric Christopher wrote: > > On Aug 21, 2012, at 2:12 PM, Michael Muller <mmuller at enduden.com> wrote: > > > > > Hi, I found a bug in the code that generates exception tables, I've attached > > what I think is the correct fix. > > > > When you run out of space writing to a buffer, the buffer management code > > simply stops writing at the