similar to: [LLVMdev] Instruction does not dominate all uses! <badref> ??

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

Hi edA-qa mort-ora-y, On 02/11/12 10:20, 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 >

Okay, I've think I understand now. By using a "Value" object (like a function call) in another instruction does nothing more than use a reference to that value. It is still my responsibility to ensure that value/reference is actually created prior to its use in the block. On 02/11/12 12:16, Nick Lewycky wrote: > edA-qa mort-ora-y wrote: >> I'm having trouble figuring

I'm having an issue where a certain set of types and insert/extractvalue are producing the incorrect values. It appears as though extractvalue getting my sub-structure is not getting the correct data. I have these types: %outer = type { i32, %inner, i1 } %inner = type { double, i32 } The trouble is that when I have a value of type %outer then proceed to extract the components of the

I also saw this issue before. Llvm seems have trouble returning general struct values from functions. One easy workaround is to use packed struct type. Hope this helps. -Peng On Sunday, December 30, 2012, edA-qa mort-ora-y wrote: > I'm having an issue where a certain set of types and insert/extractvalue > are producing the incorrect values. It appears as though extractvalue >

I'm having some trouble getting access to a global variable with getPointerToGlobal. The resulting value is not what I am expecting. My assembly looks something like this: @gresult = global i32 undef define i32 @eval_expr() { entry: ... store i32 %3, i32* @gresult ret i32 %3 } Where "gresult" is created with: auto global = new llvm::GlobalVariable( *module, int32Type,

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

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 =

I'm having trouble figuring out how to export/import IR functions at the C++ API level. I think I've got the linking part figured out, but I need to get the functions exporting from one module into another. I see how I can iterate over the functions in one, but I'm not clear on how to expose this name/reference into the other module. Is there a simple example/tutorial of this

On 03/11/13 12:16, Henrique Santos wrote: > You could try placing a phi node at "defer_block" with incoming value > "result" > when the incoming block is "entry", and do the same for "null" and > "landing". > Then, instead of loading "result", you load the value given by the newly > created phi. That seems like the

I saw something strange in the optimized LLVM code. It appears that sometimes an inlined function is optimized though the function itself is not optimized to the same level. Below is an example of an unoptimized/non-inlined function call: define void @_entry() uwtable { entry: %0 = call i64 @eval_expr() call void @trace_integer(i64 %0) ret void } 'eval_expr' is a big ugly series

I've having a bit of a problem generating output that doesn't result in the "Instruction does not dominate all uses!". In my code it relates to exception handling and how I generate the blocks. I understand exactly why I get the message, but I'm unsure of how I can structure things to avoid the problem. In a rough pseudo-code, my blocks look like this: entry: store 0,

But the incoming value from the landing pad will always be null, won't it? If so, just iterate through the predecessors and add the terminator as the incoming value if it's an invoke instruction and add the null value it's not. Won't that work? On Mon, Nov 4, 2013 at 2:22 AM, edA-qa mort-ora-y <eda-qa at disemia.com>wrote: > On 03/11/13 12:16, Henrique Santos wrote:

While adapting my JIT compiler to ToT coming from 2.5, I found this: Referencing global in another module! %3 = bitcast [8 x i8]** <badref> to i8* ; <i8*> [#uses=1]Instruction <badref> is a naked (void*) pointer. This worked on 2.5 without problem. I tried creating a GlobalVariable: external constant [8 x i8]* ; <[8 x i8]**>:<badref>

That makes it more mysterious then since I am indeed only calling a main function. Perhaps I have to invoke it a different way. Here's my call I have now: auto main = linker->getModule()->getFunction( "main" ); std::vector<llvm::GenericValue> args(2); args[0].IntVal = llvm::APInt( platform::abi_int_size, 0 ); args[1].PointerVal = nullptr; llvm::GenericValue gv =

I can confirm that if I generate the value directly (not via a return) then the expected values are extracted from the structure. So it is perhaps a return value issue. On 30/12/12 19:04, Peng Cheng wrote: > I also saw this issue before. Llvm seems have trouble returning general > struct values from functions. One easy workaround is to use packed > struct type. > > Hope this

Is there a way to get the size of a type in the IR assembly code? I know the size must be known since alloca and getelementptr both implicitly use it, but I don't see any way to get access to the size directly. I know my final compiler will have to get the size itself, but I'm just doing some simple tests directly in assembly now and am hoping there is an easy way to get the size of a

Yes, but why is it even copying the memory?  It already has a pointer which it can cast and load from -- and does so in other scenarios. I'm wondering whether this copying is somehow required and I'm missing something, or it's just an artifact of the clang emitter. That is, could it not omit the memcpy and cast the original variable? On 18/04/18 19:43, Krzysztof Parzyszek via

I'm creating a struct of `{i8,i64}` and `DataLayout::getTypeAllocSize` is returning `12`. `getStructLayout` also gives an `4` offset for the second element. The native ABI, and clang, for the same type are producing a size of 16, with an alignment of 8, for the second element. This is for the system triple "x86_64-linux-gnu" What could be causing this difference in alignment and

It was the return type which was i64. I changed it also to my abi_int_size and it works now. I have to take care of a few other type translations, but it looks like MCJIT is working now. Thank you. On 08/11/13 18:12, Yaron Keren wrote: > Something must be wrong with the Function Type. Try to debug into > runFunction to see which if condition fails. > Just a guess, if this is on 64