[llvm-dev] Changes to 'ADJCALLSTACK*' and 'callseq_*' between LLVM v4.0 and v5.0

Martin J. O'Riordan via llvm-dev llvm-dev at lists.llvm.org
Fri Sep 15 05:09:19 PDT 2017


Hi LLVM-Devs,

I have managed to complete updating our sources from LLVM v4.0 to v5.0, but
I am getting selection errors for 'callseq_end'.  I am aware that the
'ADJCALLSTACKUP' and 'ADJCALLSTACKDOWN' patterns have changed, and have
added an additional argument to the TD descriptions for these.

There are interactions with 'ISD::CALL' and 'ISD::RET_FLAG', but so far as I
can tell I have revised these in the same way as the in-tree targets have
adjusted their sources.

The error I am seeing is:

  fatal error: error in backend: Cannot select: 0x15c9bbe00: ch,glue =
callseq_end 0x15c9bbd98, TargetConstant:i32<0>, TargetGlobalAddress:i32<void
(i8*, i32, i8*, i8*)* @__assert_func> 0, 0x15c9bbd98:1
    0x15c9bb920: i32 = TargetConstant<0>
    0x15c9bb8b8: i32 = TargetGlobalAddress<void (i8*, i32, i8*, i8*)*
@__assert_func> 0
    0x15c9bbd98: ch,glue = MYISD::CALL 0x15c9bbcc8,
TargetGlobalAddress:i32<void (i8*, i32, i8*, i8*)* @__assert_func> 0,
Register:i32 %I18, Register:i32 %I17, Register:i32 %I16, Register:i32 %I15,
RegisterMask:Untyped, 0x15c9bbcc8:1
      0x15c9bb8b8: i32 = TargetGlobalAddress<void (i8*, i32, i8*, i8*)*
@__assert_func> 0
      0x15c9bb9f0: i32 = Register %I18
      0x15c9bbac0: i32 = Register %I17
      0x15c9bbb90: i32 = Register %I16
      0x15c9bbc60: i32 = Register %I15
      0x15c9bbd30: Untyped = RegisterMask
      0x15c9bbcc8: ch,glue = CopyToReg 0x15c9bbbf8, Register:i32 %I15,
0x15c9bb718, 0x15c9bbbf8:1
        0x15c9bbc60: i32 = Register %I15
        0x15c9bb718: i32,ch,glue = CopyFromReg 0x15c9bb648:1, Register:i32
%vreg2, 0x15c9bb648:1
          0x15c9bb6b0: i32 = Register %vreg2
        0x15c9bbbf8: ch,glue = CopyToReg 0x15c9bbb28, Register:i32 %I16,
Constant:i32<0>, 0x15c9bbb28:1
          0x15c9bbb90: i32 = Register %I16
          0x15c9bb850: i32 = Constant<0>
          0x15c9bbb28: ch,glue = CopyToReg 0x15c9bba58, Register:i32 %I17,
0x15c9bb648, 0x15c9bba58:1
            0x15c9bbac0: i32 = Register %I17
            0x15c9bb648: i32,ch,glue = CopyFromReg 0x15c9bb578:1,
Register:i32 %vreg1, 0x15c9bb578:1
              0x15c9bb5e0: i32 = Register %vreg1
            0x15c9bba58: ch,glue = CopyToReg 0x15c9bb988, Register:i32 %I18,
0x15c9bb578
              0x15c9bb9f0: i32 = Register %I18
              0x15c9bb578: i32,ch,glue = CopyFromReg 0x15c967b38,
Register:i32 %vreg0
                0x15c9bb510: i32 = Register %vreg0

My TD for this has:

  def SDT_MYCallSeqStart : SDCallSeqStart<[SDTCisVT<0, i32>, SDTCisVT<1,
i32>]>;
  def SDT_MYCallSeqEnd   : SDCallSeqStart<[SDTCisVT<0, i32>, SDTCisVT<1,
i32>]>;
  def MYCallseqStart     : SDNode<"ISD::CALLSEQ_START", SDT_MYCallSeqStart,
                                  [SDNPHasChain, SDNPOutGlue]>;
  def MYCallseqEnd       : SDNode<"ISD::CALLSEQ_END",   SDT_MYCallSeqEnd,
                                  [SDNPHasChain, SDNPOptInGlue,
SDNPOutGlue]>;

  def SDT_MYCall         : SDTypeProfile<0, 1, [SDTCisVT<0, i32>]>;
  def SDT_MYRet          : SDTypeProfile<0, 0, []>;
  def MYcall             : SDNode<"MYISD::CALL",     SDT_MYCall,
                                  [SDNPHasChain, SDNPOptInGlue, SDNPOutGlue,
SDNPVariadic]>;
  def MYret              : SDNode<"MYISD::RET_FLAG", SDTNone,
                                  [SDNPHasChain, SDNPOptInGlue,
SDNPVariadic]>;

  let hasCtrlDep = 1, hasSideEffects = 1 in {
    def ADJCALLSTACKDOWN : Pseudo<(outs), (ins i32imm:$amt1, i32imm:$amt2),
                                  [(MYCallseqStart timm:$amt1,
timm:$amt2)]>;
    def ADJCALLSTACKUP   : Pseudo<(outs), (ins i32imm:$amt1, i32imm:$amt2),
                                  [(MYCallseqEnd timm:$amt1, timm:$amt2)]>;
  }

  def: Pat<(MYret), (JMP_Ret (i32 LR))>;

The function that is failing does warn - "warning: function declared
'noreturn' should not return [-Winvalid-noreturn]", and it does seem to
return.  In fact it invokes a custom builtin which does not actually return.
In the past I have just ignored this warning.

Any hints that might help me to make the necessary adaptations to fix this?

Thanks in advance,

	MartinO

PS: I won't be able to reply until Monday as I will be away for the weekend




More information about the llvm-dev mailing list