On Tuesday 08 December 2009 14:43, David Greene wrote:> 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 go is to mark routines with thread-local storage > > accesses in them as non-leaf. I guess that would have to happen in > > the PrologueEpilogueInserter. > > > > Is there an easy way to tell if a MachineFunction uses TLS without doing > > a full scan of the body? Perhaps SelectionDAG will have to mark the > > function somehow. > > How does a MachineInstr acquire a CallFrameSetupOpcode? I can't find > 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 adjustment in the final code. How does this all work? How do I convince codegen to adjust the stack even though it thinks it's a leaf routine? Where do I have to toggle things to either have it generate the stack adjustment or not delete it? -Dave
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 only one stack > adjustment in the final code.Right. Every call is surrounded by callseq_{start,end} nodes. The difference here is that call to special symbol is not real, it's not generated by lowering of the ISD::CALL node, thus no callseq stuff is ever generated. You might want to look into TLS lowering code inside X86ISelLowering.cpp to introduce yourself into this this. With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
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 surely there's only one stack > > adjustment in the final code. > > Right. Every call is surrounded by callseq_{start,end} nodes. The > difference here is that call to special symbol is not real, it's not > generated by lowering of the ISD::CALL node, thus no callseq stuff is > ever generated. > > You might want to look into TLS lowering code inside > X86ISelLowering.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. Where in the backend is the operation to create and destroy the stack frame either inserted or deleted? That's where I need to make a change. -Dave