similar to: [LLVMdev] replacing GetElementPtrConstantExpr with GetElementPtrInst ... sometimes

Hi all, I just come across an IR instruction like this: %0 = getelementptr i32* getelementptr inbounds ([42 x i32]* @aaa, i32 0, i32 0), i32 %2 What does the part "i32* getelementptr inbounds ([42 x i32]* @aaa, i32 0, i32 0)" mean? As far as I could understand this is a GetElementPtrConstantExpr, isn't it? My question is: how can I instantiate a class that represents that

Hmm... if I do a print() on the result of getFileName(), I get i8 * getelementptr ([9 x i8]* @.str, i32 0, i32 0) back, but if I try to dyn_cast this to GetElementPtrInst it fails (returning null), so presumably I'm seeing a GetElementPtrConstantExpr... so how can I get at that constant i8 array without casting to a GetElementPtrInst, and with GetElementPtrConstantExpr being

On Sat, Nov 22, 2014 at 11:09 AM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > Hi Qiuping, > > If I'm reading the IR correctly, what you have is a > GetElementPtrConstantExpr [1]. It subclasses from llvm::Constant. > If you want the same code to handle GetElementPtrConstantExpr *and* GetElementPtrInst, you can use GEPOperator. > > Thanks, > --

I collected a sequence of LLVM instructions, want to make a copy of each and insert them into a PREVIOUS location inside the same function (all globals and locals are properly declared before the PREVIOUS location). Here is the list of instructions I want to duplicate and insert: 0 %90 = load i32* @strstart, align 4 1 %91 = add i32 %90, 2 2 %88 = load i32* @ins_h, align 4 3 %92 =

Hi Chuck, > std::vector<Instruction *>::iterator p; > Instruction * pi = PREVIOUS_POSITION; > BasicBlock * pb = PREVIOUS_POSITION->getParent(); > > for(p = coll.begin(); p != coll.end(); ++p){ > Instruction * CurI = * p; > Instruction * CloneI = CurI->clone(); clone doesn't know have any magical way of knowing that it should update the instruction's

While it is great that LLVM has an IR Verifier, its a little troublesome to use because it separates the point of detection from the source of the problem. That is, the verifier gets run on a module or function after its been built. By that point, the compiler's state has moved past the point at which the error was placed into the module or function. Trying to track down the source of the

Thanks for the quick response. I wrote some code to search “llvm.dbg.cu” for the function (right before the failed assertion): if (TheCU == nullptr) { errs() << "compile unit: " << TheCU << "\n scopeNode(" << FnScope->getScopeNode() << ") => " << *FnScope->getScopeNode() << "\n"; auto fn =

On Tue, Dec 3, 2013 at 10:07 PM, Brandon Holt <bholt at cs.washington.edu> wrote: > Thanks for the quick response. > > I wrote some code to search “llvm.dbg.cu” for the function (right before the > failed assertion): > > if (TheCU == nullptr) { > errs() << "compile unit: " << TheCU << "\n scopeNode(" << >

In your transform I'd take a look at things like the individual basic blocks you're replacing and the functions you're replacing and making sure that the various lexical blocks are being changed at the same time... -eric On Tue, Dec 3, 2013 at 11:12 PM, David Blaikie <dblaikie at gmail.com> wrote: > On Tue, Dec 3, 2013 at 10:07 PM, Brandon Holt <bholt at

How do I find and update the lexical blocks? Is, for example, “CloneFunction” doing this in a way I can copy? I tried finding the subprogram node in “llvm.dbg.cu” and updating the function: DISubprogram s(*subprog_iter); if (s.getFunction() == F) { s.replaceFunction(NF); } But this didn’t seem to have any effect. Do I need to do something similar with every basic block or something? On Dec

On Tue, Dec 3, 2013 at 9:04 PM, Brandon Holt <bholt at cs.washington.edu> wrote: > In a pass I’m working on, I’ve done some manipulation of several functions, replacing them with new copies with different types, etc. > > The LLVM IR passes the verifier, but when I have debug symbols enabled (“-g”), I get the following error when Clang generates the Dwarf info (using a very recent

I'm having trouble figuring out what the error "Instruction does not dominate all uses!" means. I'm trying to construct a call to a function with two parameters. The printed IR, with error, looks like this: define i32 @add(i32, i32) { EntryBlock: %2 = add i32 %0, %1 ret i32 %2 } define i32 @eval_expr() { EntryBlock: ret i32 <badref> } Instruction does not dominate

In a pass I’m working on, I’ve done some manipulation of several functions, replacing them with new copies with different types, etc. The LLVM IR passes the verifier, but when I have debug symbols enabled (“-g”), I get the following error when Clang generates the Dwarf info (using a very recent build of LLVM/Clang from Git mirror): > Assertion failed: (TheCU && "Unable to find

For everyone understand which code must be emitted to implement TLS, I will paste the code generated by gcc for a simple function: __thread int a = 1; int f(){ return a; } gcc teste.c -o teste.s -S -O2 (arm-linux-gnueabi): .global a .section .tdata,"awT",%progbits <== special section for tls symbols .align 2 .type a, %object

Hi David, I'm seeing an assertion failure when passing this node !{i32 786454, metadata <badref>, metadata <badref>, metadata !"fn_t", i32 5, i64 0, i64 0, i64 0, i32 0, metadata <badref>} ; [ DW_TAG_typedef ] [fn_t] [line 5, size 0, align 0, offset 0] [from ] as the function type parameter to DIBuilder::createFunction, due to this check in DebugInfo.cpp:

edA-qa mort-ora-y wrote: > I'm having trouble figuring out what the error "Instruction does not > dominate all uses!" means. I'm trying to construct a call to a function > with two parameters. The printed IR, with error, looks like this: > > define i32 @add(i32, i32) { > EntryBlock: > %2 = add i32 %0, %1 > ret i32 %2 > } > > define i32

Thanks Tim, I'll try to solve my problem ASAP, if I cannot maybe I'll some other clarifications. Thanks again On Sat, Mar 9, 2019, 06:03 Tim Northover <t.p.northover at gmail.com> wrote: > Hi Alberto, > > On Sat, 9 Mar 2019 at 05:50, Alberto Barbaro via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > i8* getelementptr inbounds ([7 x i8], [7 x i8]*

On Tue, Apr 9, 2013 at 1:53 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi David, I'm seeing an assertion failure when passing this node > > !{i32 786454, metadata <badref>, metadata <badref>, metadata !"fn_t", i32 > 5, i64 0, i64 0, i64 0, i32 0, metadata <badref>} ; [ DW_TAG_typedef ] > [fn_t] [line 5, size 0, align 0, offset 0] [from ]

We know that in C++, the constructor of a static member will get called when the program starts up. I checked the generated IR code and found this is implemented by defining a __cxx_global_var_init() function and marked it as section ".text.startup" and assign it to @llvm.global_ctors. We also know that in C++, the constructor of a static thread_local member will *not* get called when

On Fri, 21 Nov 2003, Reid Spencer wrote: > While it is great that LLVM has an IR Verifier, its a little troublesome > to use because it separates the point of detection from the source of > the problem. That is, the verifier gets run on a module or function > after its been built. By that point, the compiler's state has moved past Well, you can run the verifier any time you want: