search for: sdnpvariad

...>; 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),...

...: 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:...

...i32>, SDTCisVT<1, i32>]>, [SDNPHasChain, SDNPOptInGlue, SDNPOutGlue]>; def my_call : SDNode<"MyISD::CALL", SDTypeProfile<0, -1, [SDTCisPtrTy<0>]>, [SDNPHasChain, SDNPOptInGlue, SDNPOutGlue, SDNPVariadic]>; def my_ret : SDNode<"MyISD::RET_FLAG", SDTNone, [SDNPHasChain, SDNPOptInGlue, SDNPVariadic]>; let hasCtrlDep = 1, hasSideEffects = 1, isCodeGenOnly = 1, Defs = [SP], Uses = [SP] in { def ADJCALLSTACKDOWN : Pseudo<...

...s (I'm not) > help me root out the problem? Anton graciously helped me out of band. I'm attaching his patch (recomputed against ToT), which fixes a bug in MSP430InstrInfo.td. I'm afraid I don't know how to write a testcase for this bug. (Key insight from Anton: attaching "SDNPVariadic" to "MSP430call" indicates that the *instruction selector pattern*, not the call instruction, is variadic.) -ben -------------- next part -------------- A non-text attachment was scrubbed... Name: msp430-call-variadic.patch Type: application/octet-stream Size: 677 bytes Desc: not...

...make three changes: 1. The XXXretflag SDNode needs to be variadic like the call SDNodes are: --- a/lib/Target/ARM/ARMInstrInfo.td +++ b/lib/Target/ARM/ARMInstrInfo.td @@ -117,7 +117,7 @@ def ARMcall_nolink : SDNode<"ARMISD::CALL_NOLINK", SDT_ARMcall, SDNPVariadic]>; def ARMretflag : SDNode<"ARMISD::RET_FLAG", SDTNone, - [SDNPHasChain, SDNPOptInGlue]>; + [SDNPHasChain, SDNPOptInGlue, SDNPVariadic]>; def ARMcmov : SDNode<"ARMISD::CMOV", SDT_ARMC...

Hello, Yesterday I noticed that MSP430 argument passing is broken in trunk; see http://llvm.org/PR6573 for details and testcases. The problem is that calls aren't being preceded by instructions that put the arguments into registers. I backtracked my working copy and then stepped forward until it broke between r98937 and r98938. Refining further, I found that rolling back the

Hi, I write a backend and come cross an abnormal problem. Here I give a example to describe it: /////////////////////////////////////////////////////////////////////////////////////////// // A simple C function int foo() { return 1234; } ///////////////////////////////////////////////////////////////////////////////////////// When compiling foo() into my target ISA, I would expect codes

Hi, > The headache is when I pass option -O0 to llc, the generated codes are > correct. However, if I omit -O0 and use default compiling options, the > instruction "movi r0, #1234" does not show. It's probably being eliminated as dead code. You want to make sure that during ISelLowering your RET instruction has %R0 as one of its operands (check in the -view-isel-dags