[CIR] introduce cir.unreachable operation

[Lancern]

In #426 we confirmed that CIR needs a cir.unreachable operation to mark unreachable program points (discussion). This PR adds it.

[bcardosolopes]

This is awesome. Since you're adding support for this, let's make it complete while you're here, see other mentions in:

• clang/lib/CIR/CodeGen/CIRGenExprCXX.cpp:760
• clang/lib/CIR/CodeGen/CIRGenFunction.cpp:589
• Add CIRGen for __builtin_unreachable, which should map into this operation.

[Lancern]

Add CIRGen for __builtin_unreachable, which should map into this operation.

Added. The codegen slightly diverges from upstream clang. The problem one needs to resolve when emitting calls to noreturn functions like __builtin_unreachable is how should we deal with any code that follows such calls:

void test() {
  __builtin_unreachable();

  // How should we deal with the following code?
  do_some_thing_that_may_never_happen();
}

We cannot continue emitting code after cir.unreachable or llvm.unreachable because they are block terminators. The solution is, after emitting cir.unreachable or llvm.unreachable, we immediately start a new block that does not have any predecessors (let's call it "the dangling block") and any code following will be emitted there.

In upstream Clang, the codegen of statements are allowed to erase the current insertion point. Thus, after emitting the full statement that contains a call to __builtin_unreachable, the dangling block will be erased immediately and the code builder no longer has an insertion point.

However, in CIRGen, there are already too many assumptions in the code that the insertion point is always present. So we can't erase the dangling block until the function CIRGen is fully complete. In this PR, the removal of the dangling block is not implemented. I believe we should invent a DCE pass in the future to remove these dangling blocks (I guess there is already one in MLIR).

clang/lib/CIR/CodeGen/CIRGenExprCXX.cpp:760

Updated.

clang/lib/CIR/CodeGen/CIRGenFunction.cpp:589

This place handles control flows that implicitly returns from a function with a non-void return type. In such a circumstance we want to insert a cir.unreachable operation to terminate the implicitly-returning block. However, when the LexicalScope object that represents the whole function body is destroyed, it already inserts cir.return operations at every returning path. So I believe a better place for emitting cir.unreachable here should be in the LexicalScope::cleanup function. This change may get a little large and I'm still working on it.

[bcardosolopes]

We cannot continue emitting code after cir.unreachable or llvm.unreachable because they are block terminators. The solution is, after emitting cir.unreachable or llvm.unreachable, we immediately start a new block that does not have any predecessors (let's call it "the dangling block") and any code following will be emitted there.

That's right!

In upstream Clang, the codegen of statements are allowed to erase the current insertion point. Thus, after emitting the full statement that contains a call to __builtin_unreachable, the dangling block will be erased immediately and the code builder no longer has an insertion point. However, in CIRGen, there are already too many assumptions in the code that the insertion point is always present.

We take a different approach here. Upstream codegen relies too much on insertion point availability in order to take decisions, and although it works, it feels hacky because you are not really aware at any given point, why is it that an insertion point isn't available - is it because of a bug? is it because it's trying to signal something? if so, signal what? Overall I find it very hard to rely. It's also becomes a bit cumbersome when dealing with structured control flow in CIRGen. So I took the opposite direction: insert guard as much as possible so that we should assume at any point that we have BB to insert operations.

So we can't erase the dangling block until the function CIRGen is fully complete.

This is expected, we want dangling blocks to be around because in the future we want to emit "unreachable" warnings in Clang using CIR. This is an early optimization that upstream does, which we don't want in ClangIR. Some later cleanup pass should remove it before LLVM lowering, but CIRGen should emit them normally.

In this PR, the removal of the dangling block is not implemented. I believe we should invent a DCE pass in the future to remove these dangling blocks (I guess there is already one in MLIR).

Yes, or alternatively apply it in MergeCleanups, whatever that pass is in the future, it should run after LoweringPrepare.

clang/lib/CIR/CodeGen/CIRGenExprCXX.cpp:760

Updated.

Very nice, thanks for updating the testcase too.

This place handles control flows that implicitly returns from a function with a non-void return type. In such a circumstance we want to insert a cir.unreachable operation to terminate the implicitly-returning block. However, when the LexicalScope object that represents the whole function body is destroyed, it already inserts cir.return operations at every returning path. So I believe a better place for emitting cir.unreachable here should be in the LexicalScope::cleanup function. This change may get a little large and I'm still working on it.

Fair, totally a "follow up PR" material. Let me track this in a new issue.

As a last request for this PR, can you then change the comment in clang/lib/CIR/CodeGen/CIRGenFunction.cpp:589 and add a assert(!UnimplementedFeature::unreachableOp()); there? This will mean that for now we should keep unreachableOp() around!

[Lancern]

Updated. Also rebased onto the latest main.

[bcardosolopes]

Awesome, LGTM