search for: curbb

...- if (EltOffset*EltSize == Offset) { - // If this is a subtract, we want to step backwards. - if (Opc == Instruction::Sub) - EltOffset = -EltOffset; - Constant *C = ConstantSInt::get(Type::LongTy, EltOffset); - Value *V = new GetElementPtrInst(LHS, C, "tmp", CurBB); - return CastToType(V, TREE_TYPE(exp)); + // If EltSize exactly divides Offset, then we know that we can turn + // this into a getelementptr instruction. + int64_t EltOffset = Offset/EltSize; + if (EltOffset*EltSize == Offset) { + // If this is a subtract, we wan...

...t;Value*> Ops; Ops.push_back(CastToType(DestPtr, SBP)); Ops.push_back(CastToType(SrcPtr, SBP)); - Ops.push_back(CastToType(Size, Type::UIntTy)); + Ops.push_back(CastToType(Size, IntPtr)); Ops.push_back(ConstantUInt::get(Type::UIntTy, Align)); new CallInst(MemCpy, Ops, "", CurBB); } @@ -811,14 +815,17 @@ void TreeToLLVM::EmitMemMove(Value *Dest unsigned Align) { const Type *SBP = PointerType::get(Type::SByteTy); static Function *MemMove = 0; - if (!MemMove) - MemMove = TheModule->getOrInsertFunction("llvm.memmove", Type...

...Align) }; new CallInst(Intrinsic::getDeclaration(TheModule, (IntPtr == Type::Int32Ty) ? Intrinsic::memcpy_i32 : Intrinsic::memcpy_i64), Ops, 4, "", CurBB); } The problem is that Intrinsic::getDeclaration takes four parameters but is only passed two: Function *Intrinsic::getDeclaration(Module *M, ID id, const Type **Tys, unsigned numTys) So it sees bogus data from Tys and numTys. This probably works in the off...

On Thu, 2 Mar 2006, Vladimir Prus wrote: >>> The instructions seem to have one path wrong. It says to get: >> >> I'll put together a tarball today. That will be easier than dealing with >> a patch, and it will include a bunch of bugfixes since the previous email. > Further into process, I get this error: > In file included from

...ached patch helps a bit but it needs more work. Also, I suppose you might need to uncomment this bit in llvm-backend.cpp as well: // Disabled until PR1224 is resolved. //if (flag_exceptions) // Args.push_back("--enable-eh"); Some comments on the patch: (1) new UnreachableInst(CurBB); + } else { + new UnwindInst(UnwindBB); } -#endif +#else new UnwindInst(UnwindBB); +#endif This avoid generating an unwind instruction straight after an unreachable instruction, i.e. two terminators in a row. (2) - FuncCPPPersonality = cast<Function>( + FuncCPPPersonal...

On Fri, 6 Apr 2007, Nicolas Geoffray wrote: > Like you say, it's not functional for non-calls instructions. Besides, > having to change all CalInst to InvokeInst is just too much pain in our > current vm. ok. > Actually, why is it missing? What's the difference between the code > generator and the JIT? There are two things missing: 1. Testing and working out the set

Hi Chris, Chris Lattner wrote: >> We can not use current exception handling in llvm, see >> http://www.nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt. >> > > Why not? > > Like you say, it's not functional for non-calls instructions. Besides, having to change all CalInst to InvokeInst is just too much pain in our current vm. > There are two

...r everything, and everything will still work fine) but are quite handy when trying to read the LLVM code. It would be straight-forward to add a new "easy" interface for creating LLVM instructions. Would something like this work well for you? class InstructionCreator { BasicBlock *CurBB; public: void setCurrentBlock(BasicBlock *); Value *createAdd(Value *LHS, Value *RHS, const std::string &Name = ""); Value *createSub(Value *LHS, Value *RHS, const std::string &Name = ""); ... }; Given this, use would be much more implicit: InstructionCrea...

>>>>> "Chris" == Chris Lattner <sabre at nondot.org> writes: >> FWIW I actually did this work twice, once for libjit and once for >> LLVM. I'm happy to provide a comparison, from a jit-writing >> perspective, if you're interested. Chris> Given your experience with both, I'd be very interested in any Chris> thoughts you have on