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