[LLVMdev] PR 5723
dag at cray.com
Tue Dec 8 13:19:41 PST 2009
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?
More information about the llvm-dev