Restrictions on usage of IR values in landingpad blocks?

IR & Optimizations
1

I’m wondering if there are any additional restrictions/limitations on the values that can be referenced within a landingpad block, beyond the restriction that the result of an invoke instruction cannot be referenced in its landingpad block.
I can see that Clang generates code which refers to alloca’d values. Is it also correct to refer to other values?
In a pass I’m working on, I’m finding that inserting references to other values seems to give unexpected results (which looks like undefined behaviour). Below is a somewhat cut-down snippet of a larger program where the debugtrap is sometimes being triggered (it’s not very practical to give a full example):

entry:
  ...
  %someRandomValue = load i32, ptr %someRandomValueAddr, align 4
  %cmp1 = icmp eq i32 %someRandomValue, 1234
  br i1 %cmp1, label %if.then, label %if.end

if.end
  ret i1 true

if.then:
  %exception = call ptr @__cxa_allocate_exception(i64 8)
  store ptr @.str.2, ptr %exception, align 16
  invoke void @__cxa_throw(ptr %exception, ptr @_ZTIPKc, ptr null)
          to label %unreachable unwind label %lpad

unreachable:
  unreachable

lpad:
  %6 = landingpad { ptr, i32 }
  cleanup
  %cmp2 = icmp ne i32 %someRandomValue, 1234
  br i1 %cmp2, label %shouldNeverHappen, label %shouldAlwaysHappen

shouldNeverHappen:
  ... llvm.debugtrap ...

shouldAlwaysHappen:
  ... resume ...

I would expect that the debugtrap is never triggered, so I imagine that I’m doing something invalid here.

Note that DominatorTree is indicating that %someRandomValue% dominates lpad, and verifyFunction does not pick up any issues.

The program is compiled in debug mode with ASAN enabled - the issue only occurs with this build configuration.

I would appreciate some help with this! Thanks!

2

There is no restriction on using values in a landingpad. If you are observing corrupted values, something somewhere is probably failing to properly restore the register context to what it should be after the invoke. That suggests that the problem is in the unwinder, or in the unwind data that the compiler is supposed to supply to the compiler.

If you want to debug more, I would try to get the IR into godbolt so folks can stare at the assembly and unwind info to check for compiler bugs.