Should intrinsics llvm.eh.sjlj.setjmp be with isBarrier flag?

Project Infrastructure LLVM Dev List Archives
1

Hi,

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 for.body.lr.ph (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 llvm.eh.sjlj.longjmp and unconditional jumps. But setjmp should fall through.

Is there any misunderstanding? Is there any specification reason for setting llvm.eh.sjlj.setjmp as a barrier?

Thanks in advance.

BRS//
Chen Zheng
Power Compiler Backend Developer

2

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.

Cheers.

Tim.

3

Thanks for your reply.

Patch is created https://reviews.llvm.org/D55499.

Thanks.

BRS//
Chen Zheng
Power Compiler Backend Developer

graycol.gif