Should intrinsics be with isBarrier flag?


I meet an issue when I verify machineinstrs for Powerpc testcases in llvm.

llc -mtriple=powerpc64-unknown-linux-gnu < llvm/llvm/test/CodeGen/PowerPC/sj-ctr-loop.ll -verify-machineinstrs

Bad machine code: MBB exits via unconditional fall-through but ends with a barrier instruction! ***

  • function: main
  • basic block: %bb.2 (0x100275437e8)

Content in block BB.2:

BB#2: derived from LLVM BB %for.end
Predecessors according to CFG: BB#1
%vreg2 = ADDIStocHA %X2, ga:env_sigill; G8RC_and_G8RC_NOX0:%vreg2
%vreg3 = LDtocL ga:env_sigill, %vreg2; mem:LD8[GOT] G8RC:%vreg3 G8RC_and_G8RC_NOX0:%vreg2
%vreg4 = EH_SjLj_SetJmp64 %vreg3, %CTR8<imp-def,dead>; GPRC:%vreg4 G8RC:%vreg3

Currently Powerpc sets EH_SjLj_SetJmp64 with flag isBarrier. But it is also a fall-through instruction. So it fails in machineinstr verifying.

I checked other platforms like X86 and ARM, they also set this intrinsics as barrier. For my understanding, a barrier instruction means control flow can not fall through like and unconditional jumps. But setjmp should fall through.

Is there any misunderstanding? Is there any specification reason for setting as a barrier?

Thanks in advance.

Chen Zheng
Power Compiler Backend Developer

I agree with you, the setjmp ones shouldn't be isBarrier. I suspect
the original commit mistook the name "isBarrier" as referring to a
memory fence-like construct. It's a fairly common mistake and could
easily apply here.



Thanks for your reply.

Patch is created


Chen Zheng
Power Compiler Backend Developer