search for: getint64

...LLVM IR. I created new global variable in ModulePass: bool runOnModule(llvm::Module &M) { IRBuilder<> Builder(M.getContext()); Instruction *I = &*inst_begin(M.getFunction("main")); Builder.SetInsertPoint(I); M.getOrInsertGlobal("globalKey", Builder.getInt64Ty()); GlobalVariable* gVar = M.getNamedGlobal("globalKey"); gVar->setLinkage(GlobalValue::InternalLinkage); gVar->setAlignment(Align(8)); gVar->setInitializer(Builder.getInt64(0)); gVar->setConstant(false); for (Function &F : M.functions()) {...

...balKey(Instruction* I) { IRBuilder<> Builder(I->getContext()); Builder.SetInsertPoint(I->getNextNode()); GlobalVariable* key = I->getModule()->getNamedGlobal("globalKey"); if (key) { LoadInst* load = Builder.CreateLoad(key); Value* inc = Builder.CreateAdd(load, Builder.getInt64(1)); StoreInst* store = Builder.CreateStore(inc, key); return store; } return I; } Instruction* InstructionVisitor::print(Instruction* I, const char* text, Value* arg1, Value* arg2, Value* arg3, Value* arg4) { Function* printfFn = I->getModule()->getFunction("printf"); if (printfFn...

...cast<BitCastInst>(&I); for (Use& U : I.operands()) { Value* V = U.get(); if (!dyn_cast<Instruction>(V)) { // must be a function's argument std::vector<llvm::Value*> vect_1; vect_1.push_back(Builder->getInt64(0)); llvm::GetElementPtrInst* gep1 = llvm::GetElementPtrInst::Create(V, ArrayRef< Value * >(vect_1) ); BB.getInstList().insert(&I, gep1); llvm::BitCastInst *bci = new BitCastInst (gep1, BCI->getDestTy() ); llvm::ReplaceInstWithInst...

...e::ExternalLinkage, name, &m); }; static const bool SHOW_ERROR = false; int main() { static LLVMContext ctx; static IRBuilder<> Builder(ctx); Module *m = new Module("Module", ctx); Function *F = getOrCreateFunction( *m, FunctionType::get(Builder.getInt64Ty(), {PointerType::get(Builder.getInt32Ty(), 42), PointerType::get(Builder.getInt32Ty(), 1)}, NON_VAR_ARG), "f"); auto It = F->arg_begin(); Value *Arg = &*It; It++; Value *Arg2 = &...

Hi, I need to pass some arguments to CreateCall function (as Value *). For example, I need to pass a 64 bit integer (with a value I calculate). How can I convert the 64 bit integer to a value * in order to pass it? Thanks a lot, Tehila. -------------- next part -------------- An HTML attachment was scrubbed... URL:

...!isInt64((__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, __FUNCTION__); __t; })->type.size), true) || getInt64((__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, __FUNCTION__); __t; })->type.size), true) == getTarge...

...!isInt64((__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, __FUNCTION__); __t; })->type.size), true) || getInt64((__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, __FUNCTION__); __t; })->type.size), true) == getTarge...

...n__ ({ const tree __t = (Tr); if > (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != > (tcc_type)) tree_class_check_failed (__t, (tcc_type), > "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, > __FUNCTION__); __t; })->type.size), true) || getInt64((__extension__ > ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) > (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, > (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm- > types.cpp", > 81, __FUNCTION__); __t; })->ty...

...include -I/home/ang/svn/llvm-gcc/gcc/../libdecnumber -I../libdecnumber -I/hom e/ang/build/llvm/include -I/home/ang/svn/llvm/include -DL_powixf2 -c /home/ang/s vn/llvm-gcc/gcc/libgcc2.c -o libgcc/./_powixf2.o assertion "(!TYPE_SIZE(Tr) || !Ty->isSized() || !isInt64(TYPE_SIZE(Tr), true) || getInt64(TYPE_SIZE(Tr), true) == getTargetData().getTypeAllocSizeInBits(Ty)) && "LLVM type size doesn't match GCC type size!"" failed: file "/home/ang/svn/llvm -gcc/gcc/llvm-types.cpp", line 83 This assertion has not changed from the past and am not sure what is causin...

This patch adds EmitTypeAuxAttribute() function to CGDebugInfo, which allows other parts of clang issue auxiliary information through an enumeration type in Dwarf information. For example, by calling DI->EmitTypeAuxAttribute(type, "ID", 1234); We can get following information in dwarf: <1><3f>: Abbrev Number: 3 (DW_TAG_structure_type) <40> DW_AT_name

Using the LLVM C++ API, if I want to create an array via an Alloca instruction like: Value *a = ir_builder.CreateAlloca( my_type, my_size ); and then I want to initialize each element of the array with values computed elsewhere like: for ( vector<Value*>::const_iterator i = v.begin(); i != v.end(); ++i ) { builder.CreateStore( *i, a ); // How do I increment 'a' to point to

...(CounterTy), + "__llvm_pgo_pcs"); + } void CodeGenPGO::emitCounterIncrement(CGBuilderTy &Builder, unsigned Counter) { @@ -779,6 +788,21 @@ llvm::Value *Count = Builder.CreateLoad(Addr, "pgocount"); Count = Builder.CreateAdd(Count, Builder.getInt64(1)); Builder.CreateStore(Count, Addr); + // We should put the PC of the instruction that increments __llvm_pgo_ctr + // into __llvm_pgo_pcs, which will be passed to llvm_pgo_emit. + // This patch is wrong in many ways: + // * We pass the PC of the Function instead of the PC of the Instruct...

Hi Chandler, > void > foo () { > float x __attribute__ ((mode (XF))); > } nice reduction. I don't see any problem on x86-32, and I don't have access to an x86-64 box right now. Can you please open a PR for this, and also run in the debugger. When you hit the abort, use "up" to go up a stack frame or two or three, and print out the gcc types [use: call

On Wednesday 10 October 2007 12:53, Chris Lattner wrote: > On Mon, 8 Oct 2007, Evan Cheng wrote: > > I am turning 32-bit add into 32-bit LEA on x86-64 but that's > > perfectly legal. Both > > leal (%esi,%edi), %eax > > leal (%rsi,%rdi), %eax > > are legal assembly. It's just the former requires a 67H prefix due to > > the 32-bit address size. >

...!isInt64((__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, __FUNCTION__); __t; })->type.size), true) || getInt64((__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)-> common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp", 81, __FUNCTION__); __t; })->type.size), true) == getTarg...

...64 ((__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/llvm-project.official/llvm-gcc-4.0/trunk/gcc/llvm-types.cpp", 82, __FUNCTION__); __t; })->type.size), true) || getInt64((__extension__ ({ const tree __t = (Tr); if (tree_code_type[(int) (((enum tree_code) (__t)->common.code))] != (tcc_type)) tree_class_check_failed (__t, (tcc_type), "/llvm-project.official/llvm-gcc-4.0/trunk/gcc/llvm-types.cpp", 82, __FUNCTION__); __t; })->type.size), true) == g...

On Mon, 8 Oct 2007, Evan Cheng wrote: > I am turning 32-bit add into 32-bit LEA on x86-64 but that's > perfectly legal. Both > leal (%esi,%edi), %eax > leal (%rsi,%rdi), %eax > are legal assembly. It's just the former requires a 67H prefix due to > the 32-bit address size. > > This does point to a performance problem in the 3 address conversion > code (which I

I've built chromium with " -fprofile-instr-generate -fsanitize=address" -- the performance looks good! The file format from r198638 is indeed rudimentary. Do you already know how the real output format will look like? Just to summarize what I think is important: - minimal size on disk, minimal amount of files - minimal i/o while writing to disk, no lockf or some such -