llvm::BasicBlock::isLandingPad not behaving as expected

Question

I'm a bit confused about isLandingPad on BasicBlocks in LLVM. I have the following code, where I create an empty BasicBlock and then call isLandingPad on it:

#include "llvm/IR/IRBuilder.h"
#include <assert.h>

using namespace llvm;

int main(void)
{
    // Start with a LLVM context.
    LLVMContext TheContext;

    // Make a module.
    Module *TheModule = new Module("mymod", TheContext);

    // Make a function
    std::vector<Type*> NoArgs = {};
    Type *u32 = Type::getInt32Ty(TheContext);
    FunctionType *FT = FunctionType::get(u32, NoArgs, false);
    Function *F = Function::Create(FT, Function::ExternalLinkage, "main", TheModule);

    // Make an empty block
    IRBuilder<> Builder(TheContext);
    BasicBlock *BB = BasicBlock::Create(TheContext, "entry", F);
    Builder.SetInsertPoint(BB);

    auto fnp = BB->getFirstNonPHI();
    assert(fnp == nullptr);

    // I think this should crash.
    auto islp = BB->isLandingPad();
    printf("isLP = %d\n", islp);

    // If we inline the implementation of the above call, we have the following
    // (which *does* crash).
    auto islp2 = isa<LandingPadInst>(BB->getFirstNonPHI());
    printf("isLP2 = %d\n", islp2);

    return 0;
}

which outputs:

isLP = 0
codegen: /usr/lib/llvm-7/include/llvm/Support/Casting.h:106: static bool llvm::isa_impl_cl<llvm::LandingPadInst, const llvm::Instruction *>::doit(const From *) [To = llvm::LandingPadInst, From = const llvm::Instruction *]: Assertion `Val && "isa<> used on a null pointer"' failed.

According to the LLVM source of isLandingPad (https://llvm.org/doxygen/BasicBlock_8cpp_source.html#l00470) this should segfault when the BasicBlock is empty (since we are calling isa on a nullptr). However, when I run this program the call to isLandingPad succeeds and returns false. Interestingly, when I inline the function definition of isLandingPad (as seen further below), it crashes as expected.

I'm clearly doing something wrong here, but I don't see in what way the BB->isLandingPad() call is different to the inlined version, and why isLandingPad doesn't crash, when it should according to the source.

Answer 1

If the code "should segfault", that seems to imply that the code is invoking undefined behavior (UB) at runtime. It is a possibility that the compiler is doing optimizations based on the false assumption that UB does not occur in your program and this false assumption leads to the false result isLP == false that you observe.

You should never invoke undefined behavior and restructure your code to never call functions with parameters that can call UB. (E.g., check the result of getFirstNonPHI before calling isa<LandingPadInst> or isLandingPad.

Specifically you should not assume that UB (such as dereferencing nullptr or an address near it) has a well-defined effect such as "it will segfault" because the compiler may reorganize your code (assuming UB never happens) in ways that will eliminate the effect you expect (e.g., it will generate code that doesn't attempt to load from nullptr).

Inlining and optimization levels have great effect on the generated code and this is why you see different results (invalid return value vs. segfault) in different cases.

More info on undefined behavior:

• Undefined, unspecified and implementation-defined behavior
• What Every C Programmer Should Know About Undefined Behavior
• https://en.cppreference.com/w/cpp/language/ub (See the links at the bottom of the page for further references)

Answer 2

LLVM itself is (at least on my system) compiled with assertions disabled, so the assertion doesn't trigger. When you inline it in your code, you are compiling with assertions enabled, so it does trigger.

Note that since isa<...> is a template, it will be compiled into the compilation unit it is instantiated as part of. In this case, there's at least two: one in LLVM and one that comprises your program. Strictly speaking they should both be identical (the "one definition rule") or you have UB anyway. The practical upshot in a case like this one is that calls to isa<...>() from either compilation unit might end up calling the version instantiated in the other one. However, it's likely that in the case of isa<...>() the calls are being inlined, i.e. you end up with a version of isa<...>() specific to each compilation unit that instantiates it.