similar to: [LLVMdev] conditional flow resulting in "Instruction does not dominate all uses!"

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:

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,

On 4 November 2013 02:31, Henrique Santos <henrique.nazare.santos at gmail.com> wrote: > 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? > Note that the

Well, what I had in mind was actually something like the following: entry: result0 = invoke func0 to defer_block unwind landing0 landing0: landingpad result1 = invoke func1 to defer_block unwind landing1 landing1: landingpad br defer_block defer_block: result = phi [ result0, entry ], [ result1, landing0 ], [ null, landing1 ] ... This doesn't have landing pads with multiple

On 4 November 2013 08:19, Henrique Santos <henrique.nazare.santos at gmail.com> wrote: > Well, what I had in mind was actually something like the following: > > entry: > result0 = invoke func0 to defer_block unwind landing0 > > landing0: > landingpad > result1 = invoke func1 to defer_block unwind landing1 > > landing1: > landingpad > br

If you're talking about the IR, then I don't think so. It seems like perfectly valid. H. On Mon, Nov 4, 2013 at 2:25 PM, Rafael Espíndola <rafael.espindola at gmail.com > wrote: > On 4 November 2013 08:19, Henrique Santos > <henrique.nazare.santos at gmail.com> wrote: > > Well, what I had in mind was actually something like the following: > > > >

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

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

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 >

I'm working on exception handling and having some trouble with type information. My personality/types work fine when running in the JIT, but when I produce object files and link them it fails. In particular, from an action record and the LSDA I get a type table entry. The problem is this doesn't appear to be pointing to a valid location. If I derefence it a segfault occurs. Are there

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 =

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

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

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

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 bit system the first argument type may be int64 but needs to be int32. Yaron 2013/11/8 edA-qa mort-ora-y <eda-qa at disemia.com> > That makes it more mysterious then since I am indeed only calling a main > function. Perhaps I have to invoke

Hi all, I was discussing this with a few folks at the dev meeting and it would be interesting for some passes to print some warnings on a later stage than the front-end, in special cases, especially if line information is kept and available at that stage. Is this possible today? My main concern is not correctness, that should have been taken care by the front-end and the sanitizers, but things

I think I see a potential issue. My ExecutionEngine setup may not be using the same target as my object code emitting, and in this test case I'm running in the ExecutionEngine.  I'll go over this code to ensure I'm creating the same triple and see if that helps -- I'm assuming it will, since I can't imagine the exact same triple with clang would produce a different layout. On

How would I go about getting a custom data format stored at the exception landing pads (the location _Unwind_GetLanguageSpecificData returns)? The Dwarf encoded format is not well suited for the type of exception handling I wish to do in my language. Will this be possible, or is exception handling mechanism so tightly tied to the Dwarf format that it would be extremely difficult? -- edA-qa