search for: callseq_

..., Thanks for your help. I have looked at the change log, and so far as I can tell, my implementation is pretty much identical to all of the in-tree targets, but I’m missing something and can’t see what it is. I have simplified my TD description to just: def MyCallseqStart : SDNode<"ISD::CALLSEQ_START", SDCallSeqStart<[SDTCisVT<0, i32>, SDTCisVT<1, i32>]>, [SDNPHasChain, SDNPOutGlue]>; def MyCallseqEnd : SDNode<"ISD::CALLSEQ_END", SDCallSeqEnd<[SDTCisVT<0, i32>,...

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

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

Hello, David > For X86 CALLSEQ_START gets selected to ADJCALLSTACKDOWN or > ADJCALLSTACKDOWN64 in this case.  So is CALLSEQ_START expected > to appear only once (at the top of the function)?  The comments > are rather confusing.  It seems like CALLSEQ_START is supposed > to appear before every call, but surely there...

...ind > anywhere in the sources or generated files where that opcode is set. > I believe we need to generate that instruction if it does not exist > (along with CallFrameDestroyOpcode) in the presence of TLS, at least > on X86 where's it's implemented via a function call. For X86 CALLSEQ_START gets selected to ADJCALLSTACKDOWN or ADJCALLSTACKDOWN64 in this case. So is CALLSEQ_START expected to appear only once (at the top of the function)? The comments are rather confusing. It seems like CALLSEQ_START is supposed to appear before every call, but surely there's only one stac...

On Tuesday 08 December 2009 15:53, Anton Korobeynikov wrote: > Hello, David > > > For X86 CALLSEQ_START gets selected to ADJCALLSTACKDOWN or > > ADJCALLSTACKDOWN64 in this case.  So is CALLSEQ_START expected > > to appear only once (at the top of the function)?  The comments > > are rather confusing.  It seems like CALLSEQ_START is supposed > > to appear before every call...

...n handle any combination of stack locations and registers. Ideally, it should not effect register allocation. The approach I've taken to date is based in part on the work done for PATCHPOINT. Here's what I've done: - Introduced a SAFEPOINT psuedo instruction - Reverse engineered the CALLSEQ_* series of nodes to insert my node after the CALL node in both glue and chain sequences. (BTW, is there any documentation on the call sequence? I think I've reverse engineered it correctly, but I'm not completely sure.) - Introduced folding logic in foldMemoryOperand (analogous to PAT...