search for: callframesetupopcode

Displaying 8 results from an estimated 8 matches for "callframesetupopcode".

2009 Dec 08
0
[LLVMdev] PR 5723
...s 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....
2009 Dec 08
2
[LLVMdev] PR 5723
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
2013 Sep 26
0
[LLVMdev] Register scavenger and SP/FP adjustments
CallFrameSetupOpcode is a pseudo opcode like X86::ADJCALLSTACKDOWN64. That means when the code is expected to be called before the pseudo instructions are eliminated. I don't know why it's not the case for you. A quick look at PEI code indicates the pseudo's should not have been removed at the time when rep...
2009 Dec 08
2
[LLVMdev] PR 5723
...ve 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...
2013 Sep 25
2
[LLVMdev] Register scavenger and SP/FP adjustments
...rget().getInstrInfo(); const TargetRegisterInfo &TRI = *TM.getRegisterInfo(); const TargetFrameLowering *TFI = TM.getFrameLowering(); bool StackGrowsDown = TFI->getStackGrowthDirection() == TargetFrameLowering::StackGrowsDown; int FrameSetupOpcode = TII.getCallFrameSetupOpcode(); int FrameDestroyOpcode = TII.getCallFrameDestroyOpcode(); if (RS && !FrameIndexVirtualScavenging) RS->enterBasicBlock(BB); for (MachineBasicBlock::iterator I = BB->begin(); I != BB->end(); ) { if (I->getOpcode() == FrameSetupOpcode || I->getOpcode...
2013 Sep 26
2
[LLVMdev] Register scavenger and SP/FP adjustments
...- SP = something different %R3<def> = tLDRspi %SP, 0, pred:14, pred:%noreg; mem:LD4[FixedStack-1] %R1<def> = tLDRspi %SP, 0, pred:14, pred:%noreg; mem:LD4[FixedStack-1] <- restore from *(NewSP+0) !! -Krzysztof On 9/26/2013 1:24 PM, Evan Cheng wrote: > CallFrameSetupOpcode is a pseudo opcode like X86::ADJCALLSTACKDOWN64. > That means when the code is expected to be called before the pseudo > instructions are eliminated. I don't know why it's not the case for you. > A quick look at PEI code indicates the pseudo's should not have been > removed...
2013 Sep 26
0
[LLVMdev] Register scavenger and SP/FP adjustments
...lt;def> = tLDRspi %SP, 0, pred:14, pred:%noreg; mem:LD4[FixedStack-1] > %R1<def> = tLDRspi %SP, 0, pred:14, pred:%noreg; mem:LD4[FixedStack-1] <- restore from *(NewSP+0) !! > > > -Krzysztof > > > > On 9/26/2013 1:24 PM, Evan Cheng wrote: >> CallFrameSetupOpcode is a pseudo opcode like X86::ADJCALLSTACKDOWN64. >> That means when the code is expected to be called before the pseudo >> instructions are eliminated. I don't know why it's not the case for you. >> A quick look at PEI code indicates the pseudo's should not have been &...
2013 Sep 26
1
[LLVMdev] Register scavenger and SP/FP adjustments
...; >> mem:LD4[FixedStack-1] >> %R1<def> = tLDRspi %SP, 0, pred:14, pred:%noreg; >> mem:LD4[FixedStack-1] <- restore from *(NewSP+0) !! >> >> >> -Krzysztof >> >> >> >> On 9/26/2013 1:24 PM, Evan Cheng wrote: >>> CallFrameSetupOpcode is a pseudo opcode like X86::ADJCALLSTACKDOWN64. >>> That means when the code is expected to be called before the pseudo >>> instructions are eliminated. I don't know why it's not the case for you. >>> A quick look at PEI code indicates the pseudo's should not...