similar to: [LLVMdev] Incrementing a pointer to array element?

Hi all, I have this problem: I'm using LLVM's C++ API, mostly `IRBuilder<>` to generate code. Some of the generated code is just storing constant data to a location provided as a function argument. Something like `ir_builder.CreateStore(get_default_data(), ptrValue)` where `get_default_data()` may return a `ConstantArray` of `i8` and `ptrValue` is a function argument. Looking

Hi Everyone, I'm quite new to LLVM and I want to update value of global variable in 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",

I don't think it's the same problem as you described. By printing I meant calling printf function and passing my global variable as one of the arguments. My code: Instruction* InstructionVisitor::incrementGlobalKey(Instruction* I) { IRBuilder<> Builder(I->getContext()); Builder.SetInsertPoint(I->getNextNode()); GlobalVariable* key =

Hello, I have written a pass that works nicely if I use it with the opt tool, as proposed by the "Writing an LLVM Pass" tutorial. Now I want to execute this pass directly when clang is executed. I use the technique described here: http://homes.cs.washington.edu/~asampson/blog/clangpass.html. The pass is loaded and executed, when I run clang with the right command line. But clang

Hello, Calling `replaceUsesOfWith` with a value in a different addrspace does not keep the addrspace of a GEP consistent. Is this known? Is this a bug or expected behaviour? Minimal counterexample link <https://gist.github.com/bollu/152ba5e1c20c03c7fc6d8c7b23ba828f> Reproduced here: #include <iostream> #include "llvm/ADT/APFloat.h" #include

Hello, I have an optimisation issue in an llvm IR pass - the issue being that unnecessary instructions are generated in the final assembly (with -O3). I want to create the following assembly snippet: mov dl,BYTE PTR [rsi+rdi*1] add dl,0x1 adc dl,0x0 mov BYTE PTR [rsi+rdi*1],dl however what is created is (variant #1): mov dl,BYTE PTR [rsi+rdx*1] add dl,0x1 cmp

> > > > We may need some additional info. What kind of additional info? > I haven't put a ton of thought into > this, but I'm hoping we can either (a) use debug info as is or add some > extra (valid) debug info to support this, or (b) add an extra > debug-info-like section to instrumented binaries with the information we > need. > I'd try this data

Hi All, we have an issue with our LLVM-based JIT compiler - executing the compiled code corrupts memory (and subsequently crashes) if we alloca more than 4k of variables (more than 511 8-byte ints). The same code works on Windows 7 (32 and 64 bit), Linux, MacOS. We compile LLVM and our program with Microsoft's Visual Studio 2010. Both debug and release builds are affected. The variables

Hi Craig, On 03.07.19 17:33, Craig Topper wrote: > Don't the CreateICmp calls return a Value* with an i1 type? But then > they are added to an i8 type? Not sure that works.  I had that initially: auto cf = IRB.CreateICmpULT(Incr, ConstantInt::get(Int8Ty, 1)); auto carry = IRB.CreateZExt(cf, Int8Ty); Incr = IRB.CreateAdd(Incr, carry); it makes no difference to the generated assembly

Hi, I've been writing some optimization passes for LLVM and had good luck with the simple stuff, but I am running into all kinds of trouble trying to make copies of variables within a BasicBlock as part of a LoopPass I am trying to make copies of the variables that are in scope in the loop body like so: //Remove the existing terminator

We tested on 3.4.2 and 3.5.1. Later versions are slightly problematic to test since they don't compile with VS2010. Do you happen to know if it's fixed in one of the released versions, or if there is a workaround (chkstk?) or a bug report online? Thanks! Eph On 30.06.2015 12:58, Nicholas Chapman wrote: > It's a known issue. I believe it's fixed in trunk however. >

Hi everyone, I am trying to call an LLVM intrinsic (llvm.pow.f32), inserted with the following call: std::vector<llvm::Type *> arg_types;arg_types.push_back(llvm::Type::getFloatTy(context));auto function=llvm::Intrinsic::getDeclaration(module, llvm::Intrinsic::pow, arg_types);auto result=ir_builder->CreateCall(function, args); When I try to execute the code generated by the JIT

Hi, I have a question regarding the LLParser and the new type system rewrite when running the JIT. I think there may be a problem with the parser not picking up on named types currently defined in a given Module (global context). However, I don't have much experience with the LLVM internals so there's a good chance that I'm not fully understanding the new changes ;) For Example:

2009/8/22 Bill Wendling <isanbard at gmail.com>: > I think you might have to provide an empty list if your function doesn't > take parameters. Maybe using an irbuilder would help? It does take one parameter. Here's the important bits: // My Function extern "C" void print(double X) { printf("%f\n", X); } // Args type std::vector<const Type*>

Does the C API have an equivalent of stack storage? Via the C++ APIs one can shove the string constant on the stack via a store instruction operation on an alloca instruction--the address needed is the alloca. For example: llvm::Value* stringVar = builder.CreateAlloca(stringConstant->getType()); builder.CreateStore(stringConstant, stringVar); The stringVar is your address. Garrison On Jan

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 -

Hello, MyModel.rb, TYPES = { "type1" => 1 , "type2" => 2, "type3" => 3 }.freeze validates_inclusion_of :my_type, :in => TYPES.keys --------------------------------------- MyModelPatch.rb, base.send(:remove_const, :TYPES) base._validators[:my_type].reject!{ |validator| validator if validator.is_a? ActiveModel::Validations::InclusionValidator } TYPES =

Hello all, I would like to create a new StoreInst into a basic block. I found that I could use methods like ConstantInt::get() to provide the Value* for the first argument of the constructor of the StoreInst, but I don't know how to provide the second one. For example, if I would to do x = 1, I would like to create the "Value" object of "x" for the second argument. I

Since the getelementptrs were implicitly generated by the CreateStore/Load I'm not sure how to get access to them. So I hacked the assignment to be done thrice: once using a manual decomposition into two GEPs and stores, once using the "big" CreateStore, once via the setGlobal function, printing addresses and memory contents at each point to the degree that I have access to them.

Hi Andrew, this sounded a plausible explanation, because the X86 processor does not have an instruction to calculate the power function. So I tried the llvm.sin.f32 intrinsic, as the X86 processor family does have an instruction for that, but I still get the same problem. While you may still be right, there is at least something else going on as well. Thanks for your input, though. Taco.