[LLVMdev] PR 5723

[David Greene]

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