"UNREACHABLE executed!" error?

What does this error mean? I’m getting it from an ExecutionEngine::runFunction() call. The function I’m passing it was run through verifyFunction() right before the runFunction() call. I can’t seem to find anything that tells me what causes this, only specific (but seemingly unrelated to my problem) cases of it happening.

Which unreachable was it? The basic idea is that whichever section of code gives that assertion shouldn't be executing.

Also, what was the .ll code that gave the assertion?

-eric

The dump from the function I’m running:

define %object_structure @0() {
entry:
ret %object_structure { i8 0, %object_union [double 5.000000e+00, double false] }
}

the only output I get after the runFunction() call is:

UNREACHABLE executed!
Stack dump:
0. Running pass ‘X86 DAG->DAG Instruction Selection’ on function ‘@0

I just noticed that my union seems to look like an array…is that actually a union or do I have a problem somewhere? The code I use to generate the union is:

llvm::Constant* tempUnion = llvm::ConstantUnion::get(object_union_type,llvm::Constant::getNullValue(types[t]));
llvm::Value* goodUnion = builder.CreateInsertValue(tempUnion,data,t,“createuniontmp”);

object_union_type is union { double, i1 }, and (in this case) t is 0, and types[t] is double

I'm not quite sure on the IR union syntax. It's been somewhat fluid. That said if you attach gdb to lli and run your code through it'll let you know which particular unreachable you're running into.

-eric

Alec Benzer wrote:

The dump from the function I'm running:

define %object_structure @0() {
entry:
   ret %object_structure { i8 0, %object_union [double 5.000000e+00,
double false] }
}

Unions are almost entirely unimplemented. Sorry.

Tthe IRBuilder APIs for unions or unions in general? Either way, I was using unions as a temporary solution for a problem I was too lazy to fully figure out anyway.

Alec Benzer wrote:

Tthe IRBuilder APIs for unions or unions in general? Either way, I was
using unions as a temporary solution for a problem I was too lazy to
fully figure out anyway.

No, the IRBuilder methods work fine. It's unimplemented in the rest of the compiler, notably code generation.

Hello

I just noticed that my union seems to look like an array....is that actually
a union or do I have a problem somewhere?

Yes. Unions are pretty much broken and unimplemented. They can be
removed pretty soon (say, after 2.8)

Anton Korobeynikov wrote:

Hello

I just noticed that my union seems to look like an array....is that actually
a union or do I have a problem somewhere?

Yes. Unions are pretty much broken and unimplemented. They can be
removed pretty soon (say, after 2.8)

We've never released with unions. Could we remove them for the 2.8 release instead of afterwards when they're part of our forever forwards compatible bitcode format?

Similar to what we did to the vfcmp and ficmp instructions maybe?

I'm for it. I thought I'd seen something to that effect anyhow.

-eric

Could you not just keep the IRBuilder instructions for the union, but
have it lower it to whatever the necessary IR code is? Unions are
nice as you do not need to worry about the size, else you have to
figure out what size it needs to be if you handle it manually, and
sometime that is exceedingly difficult before code generation time,
causing a lot more code generation.

OvermindDL1 wrote:

Anton Korobeynikov wrote:

Hello

I just noticed that my union seems to look like an array....is that actually
a union or do I have a problem somewhere?

Yes. Unions are pretty much broken and unimplemented. They can be
removed pretty soon (say, after 2.8)

We've never released with unions. Could we remove them for the 2.8
release instead of afterwards when they're part of our forever forwards
compatible bitcode format?

Similar to what we did to the vfcmp and ficmp instructions maybe?

I'm for it. I thought I'd seen something to that effect anyhow.

Could you not just keep the IRBuilder instructions for the union, but
have it lower it to whatever the necessary IR code is? Unions are
nice as you do not need to worry about the size, else you have to
figure out what size it needs to be if you handle it manually, and
sometime that is exceedingly difficult before code generation time,
causing a lot more code generation.

Unions are an entire new *type*. If it were merely new instructions that would certainly be feasible. The point of union is that it can express something you can't express in any other way, a type with a size of the max of a set of other types, even when you don't know those other sizes.

You can get equivalent behaviour in LLVM IR with the GEP trick[1] and alloca'ing the right about of space, but there's no way at all to make it match the API of a type.

Nick

[1] - http://nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt

Forgot the mailing list is still oddly configured compared to the
other 30 I use, sending to list...

Yeah, sounds good to me. I strongly support ripping them out of mainline completely.

-Chris

Are there any conceptual objections to the union type or is this just
due to incomplete implementation?

Eugene

There is no conceptual objection, but the current implementation is both tantalizing and useless. It is causing more damage to keep it in tree than the value it provides.

-Chris