[llvm-dev] Changes to 'ADJCALLSTACK*' and 'callseq_*' between LLVM v4.0 and v5.0
Serge Pavlov via llvm-dev
llvm-dev at lists.llvm.org
Fri Sep 15 09:39:44 PDT 2017
Hi Martin,
Pseudo CALLSEQ_START was changed in r302527, commit message contains
details on the changes.
However CALLSEQ_END was not modified. If your made changes to
ADJCALLSTACKUP to add
additional argument, that may result in error.
Thanks,
--Serge
2017-09-15 19:09 GMT+07:00 Martin J. O'Riordan via llvm-dev <
llvm-dev at lists.llvm.org>:
> 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
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170915/88bef271/attachment.html>
More information about the llvm-dev
mailing list