search for: callframedestroyopcode

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

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

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