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