search for: callseq_start

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

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

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

Hello, David > Ah, ok. I think I know what I have to do. I'll put callseq_start/end nodes > around the TLS addressing. Don't do that (tm) I'm testing the fix. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

On Tuesday 08 December 2009 14:00, David Greene wrote: > I just filed PR 5723. This is a rather serious bug for us, > causing all sorts of problems in creating dynamically-linked > C++ programs due to the C++ runtime containing lots of leaf-like > routines that use thread-local storage. > > I can imagine a number of hackish workarounds, but I think probably > the right way to

I just filed PR 5723. This is a rather serious bug for us, causing all sorts of problems in creating dynamically-linked C++ programs due to the C++ runtime containing lots of leaf-like routines that use thread-local storage. I can imagine a number of hackish workarounds, but I think probably the right way to go is to mark routines with thread-local storage accesses in them as non-leaf. I guess

...5c9bb510: 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 : SDTypePr...

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

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

...cpp to introduce yourself into this this. > > I looked at that but it's not very helpful. It just creates some generic > instructions that get emitted as a code sequence. It doesn't say anything > about the stack frame. Ah, ok. I think I know what I have to do. I'll put callseq_start/end nodes around the TLS addressing. -Dave

On Wednesday 09 December 2009 12:30, Anton Korobeynikov wrote: > Hello, David > > > Ah, ok. I think I know what I have to do. I'll put callseq_start/end > > nodes around the TLS addressing. > > Don't do that (tm) Why not? > I'm testing the fix. Ok, I'll try to "mark noredzone" thing and see if that works. -Dave

...all sequence: t0: ch = EntryToken t2: i64,ch,glue = CopyFromReg t0, Register:i64 %reg0 t4: i64,ch,glue = CopyFromReg t2:1, Register:i64 %reg1, t2:1 t6: i64,ch,glue = CopyFromReg t4:1, Register:i64 %reg2, t4:1 t8: i64,ch,glue = CopyFromReg t6:1, Register:i64 %reg3, t6:1 t46: ch,glue = callseq_start t0, TargetConstant:i32<0> t47: ch,glue = CopyToReg t46, Register:i64 %reg0, t2 t48: ch,glue = CopyToReg t47, Register:i64 %reg1, t4, t47:1 t50: ch,glue = SHAVEISD::CALL t48, TargetExternalSymbol:i32'__divdi3', Register:i64 %reg0, Register:i64 %reg1, RegisterMask:Untyped, t48:1...

Hi, During isel lowering, the backend insertes CALLSEQ_START / CALLSEQ_END target independent nodes to the DAG. These are then selected to X86 specific instructions ADJCALLSTACKDOWN / ADJCALLSTACKUP. At these point, they have a constant arguments which corresponds to the fixed frame size for argument passing. But the size of the stack frame isn'...

...418>)> t24:1, GlobalAddress:i16<float* @x3> 0, undef:i16 t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1, GlobalAddress:i16<float* @x4> 0, undef:i16 t27: i16 = GlobalAddress<float (float, float, float, float)* @fdivfaddfmul_a> 0 t29: ch,glue = callseq_start t26:1, TargetConstant:i16<4> t31: ch,glue = CLPISD::COPY_TO_CALLEE_A t29, t23, FrameIndex:i16<0>, t29:1 t33: ch,glue = CLPISD::COPY_TO_CALLEE_A t31, t24, FrameIndex:i16<1>, t31:1 t35: ch,glue = CLPISD::COPY_TO_CALLEE_A t33, t25, FrameIndex:i16<2>, t33:1 t37: ch,glue...

Hello, I am trying to add an instruction before each function call to add/ subtract the stack pointer by a value specified at the command line. I wonder if I can do that during lowering. For example, in X86TargetLowering::LowerCALL. I appreciate it if you give me some hints how and where I can do that. Thank you, Babak

...@x3> 0, undef:i16 > >   t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1, > GlobalAddress:i16<float* @x4> 0, undef:i16 > >   t27: i16 = GlobalAddress<float (float, float, float, float)* > @fdivfaddfmul_a> 0 > >   t29: ch,glue = callseq_start t26:1, TargetConstant:i16<4> > >   t31: ch,glue = CLPISD::COPY_TO_CALLEE_A t29, t23, FrameIndex:i16<0>, > t29:1 > >   t33: ch,glue = CLPISD::COPY_TO_CALLEE_A t31, t24, FrameIndex:i16<1>, > t31:1 > >   t35: ch,glue = CLPISD::COPY_TO_CALLEE_A t33, t25...

Hi, Is there a kind of scope mechanism in the instruction lowering pattern language in order to control where instructions are inserted or how they are later reordered during the SelectionDiag linearization? I know the glue chain that stick instructions together. But such mechanism in not provided in instruction lowering pattern. I'm facing many situations where some patterns are lowered into

...DAG: BB#0 '_Z3fn2v:entry' SelectionDAG has 122 nodes: t4: i64 = GlobalAddress<void (%class.F*)* @_Z10EmitLValuev> 0 t10: i64 = add Register:i64 %X1, Constant:i64<32> t0: ch = EntryToken t3: ch = lifetime.start t0, TargetFrameIndex:i64<1> t7: ch,glue = callseq_start t3, TargetConstant:i64<32>, TargetConstant:i64<0> t12: ch,glue = CopyToReg t7, Register:i64 %X3, FrameIndex:i64<1> t16: ch,glue = PPCISD::CALL_NOP t12, TargetGlobalAddress:i64<void (%class.F*)* @_Z10EmitLValuev> 0, Register:i64 %X3, Register:i64 %X2, RegisterMask:Untyped...

...@x3> 0, undef:i16 > >   t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1, > GlobalAddress:i16<float* @x4> 0, undef:i16 > >   t27: i16 = GlobalAddress<float (float, float, float, float)* > @fdivfaddfmul_a> 0 > >   t29: ch,glue = callseq_start t26:1, TargetConstant:i16<4> > >   t31: ch,glue = CLPISD::COPY_TO_CALLEE_A t29, t23, > FrameIndex:i16<0>, > t29:1 > >   t33: ch,glue = CLPISD::COPY_TO_CALLEE_A t31, t24, > FrameIndex:i16<1>, > t31:1 > >   t35: ch,glue = CLPISD::COPY_TO_CALLEE_...

...tively... -Operation EntryToken has number 0 -Operation Constant has number 1 -Operation FrameIndex has number 2 -Operation undef has number 3 -Operation store has number 4 -Operation GlobalAddress has number 5 -Operation GlobalAddress has number 6 -Operation TargetConstant has number 7 -Operation callseq_start has number 8 -Operation TargetGlobalAddress has number 9 -Operation Register has number 10 -Operation CopyToReg has number 11 -Operation RegisterMask has number 12 -Operation MipsISD::JmpLink has number 13 -Operation TargetConstant has number 14 -Operation TargetConstant has number 15 -Operation ca...