search for: framesetup

...instruction to change its value after it was stored to the stack. Mips does this by looking at the number of callee-saved registers spilled for this function and skipping over that many instructions. Other backends such as AArch64 or X86 will skip over all instruction marked with the MachineInstr::FrameSetup flag[1]. >From my point of view, skipping over all FrameSetup instructions sounds like the more robust way to go about things. I haven't fully traced through where the flag is used in LLVM, but it does seem that DwarfDebug::findPrologueEndLoc will return the wrong result if the flag isn'...

...OV64ri 40040 %R11<def> = MOV64ri 32 CALL64pcrel32 <es:__morestack>, %RSP<imp-use> MORESTACK_RET Successors according to CFG: BB#0 BB#0: derived from LLVM BB %0 Predecessors according to CFG: BB#3 BB#4 %EAX<def> = MOV32ri 40040; flags: FrameSetup %RDX<def> = MOV64rr %RAX; flags: FrameSetup %RCX<def> = MOV64rr %RSP; flags: FrameSetup Successors according to CFG: BB#1 BB#1: derived from LLVM BB %0 Predecessors according to CFG: BB#0 BB#1 OR64mi8 %RCX, 1, %noreg, 0, %noreg, 0, %EFLAGS<imp-def>...

On Tue, Jul 28, 2015 at 6:34 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Jul 28, 2015 at 2:25 AM, John Kåre Alsaker > <john.mailinglists at gmail.com> wrote: >> >> On Tue, Jul 28, 2015 at 12:44 AM, Reid Kleckner <rnk at google.com> wrote: >> > Yeah, the function attributes section of LangRef is a reasonable place >> > to >>

...ary 17, 2017 3:15 PM > To: Alex Bradbury > Cc: llvm-dev; Adrian Prantl; Eric Christopher; Robinson, Paul > Subject: Re: [llvm-dev] RFC: Setting MachineInstr flags through > storeRegToStackSlot > > Can someone familiar with debug info comment on whether it matters to have > the FrameSetup flag on the callee save spills? We could have a smart spill > or shrink wrapping algorithm that delays the callee saves to a later point > in the program while executing non-prologue code first. > > Is this maybe just meant to indicate the point at which the stack and > possible fra...

...d that prologue_end markers where badly placed in my test, and applied https://reviews.llvm.org/D41762 in the hope that it would fix it (I'm on 4.0.1). However, this fix doesn't work for VLIW architectures. At this point we're iterating over bundles, not MachineInstructions, and the FrameSetup flag is set on MachineInstructions, not bundles. If bundling happens in the prologue we might insert the prologue_end marker too early. Instead, we need to check whether all instructions in the bundle (if bundled) have the FrameSetup flag. This assumes we want the prologue_end marker just before...

...lign=4, at location [SP-4] fi#1: size=4, align=4, at location [SP-8] Function Live Ins: %R0, %R1 BB#0: derived from LLVM BB %entry Live Ins: %R0 %R1 %R7 %LR %LR %R7 %SP<def,tied1> = t2STMDB_UPD %SP<tied0>, pred:14, pred:%noreg, %R7<kill>, %LR<kill>; flags: FrameSetup CFI_INSTRUCTION <call frame instruction>; flags: FrameSetup CFI_INSTRUCTION <call frame instruction>; flags: FrameSetup CFI_INSTRUCTION <call frame instruction>; flags: FrameSetup %R7<def> = tMOVr %SP<kill>, pred:14, pred:%noreg; fla...

...s # Machine code for function main: Post SSA Frame Objects: fi#0: size=1024, align=4, at location [SP-1024] fi#1: size=1024, align=4, at location [SP-2048] BB#0: derived from LLVM BB %entry %ESP<def,tied1> = SUB32ri %ESP<tied0>, 2060, %EFLAGS<imp-def,dead>; flags: FrameSetup PROLOG_LABEL <MCSym=.Ltmp0> CALLpcrel32 <ga:@bar>, <regmask>, %ESP<imp-use>, %ESP<imp-def> %ESP<def,tied1> = ADD32ri %ESP<tied0>, 2060, %EFLAGS<imp-def,dead> RET # End machine code for function main. Let's s...

...nction main: Post SSA > Frame Objects: > fi#0: size=1024, align=4, at location [SP-1024] > fi#1: size=1024, align=4, at location [SP-2048] > > BB#0: derived from LLVM BB %entry > %ESP<def,tied1> = SUB32ri %ESP<tied0>, 2060, %EFLAGS<imp-def,dead>; flags: FrameSetup > PROLOG_LABEL <MCSym=.Ltmp0> > CALLpcrel32 <ga:@bar>, <regmask>, %ESP<imp-use>, %ESP<imp-def> > %ESP<def,tied1> = ADD32ri %ESP<tied0>, 2060, %EFLAGS<imp-def,dead> > RET > > # End machine code for functio...

...rame Objects: >> fi#0: size=1024, align=4, at location [SP-1024] >> fi#1: size=1024, align=4, at location [SP-2048] >> >> BB#0: derived from LLVM BB %entry >> %ESP<def,tied1> = SUB32ri %ESP<tied0>, 2060, >> %EFLAGS<imp-def,dead>; flags: FrameSetup >> PROLOG_LABEL <MCSym=.Ltmp0> >> CALLpcrel32 <ga:@bar>, <regmask>, %ESP<imp-use>, %ESP<imp-def> >> %ESP<def,tied1> = ADD32ri %ESP<tied0>, 2060, %EFLAGS<imp-def,dead> >> RET >> >> # End m...

...this > causes a problem? Here's the code which computes the hasCalls flag: bool HasCalls = false; for (MachineFunction::iterator BB = Fn.begin(), E = Fn.end(); BB != E; ++BB) for (MachineBasicBlock::iterator I = BB->begin(); I != BB->end(); ) if (I->getOpcode() == FrameSetupOpcode || I->getOpcode() == FrameDestroyOpcode) { ......... HasCalls = true; ........ So, stack is aligned only if there is instruction with FrameSetupOpcode or FrameDestroyOpcode. In X86, it's defined as def ADJCALLSTACKDOWN : I<0, Pseudo,...

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

...> Here's the code which computes the hasCalls flag: > > bool HasCalls = false; > > for (MachineFunction::iterator BB = Fn.begin(), E = Fn.end(); BB != E; ++BB) > for (MachineBasicBlock::iterator I = BB->begin(); I != BB->end(); ) > if (I->getOpcode() == FrameSetupOpcode || > I->getOpcode() == FrameDestroyOpcode) { > ......... > HasCalls = true; > ........ > > So, stack is aligned only if there is instruction with FrameSetupOpcode or > FrameDestroyOpcode. In X86, it's defined as > > de...

...nsigned RI = 0; + int64_t SaveSize = 0; + + for (MCPhysReg Reg : GPRs) { + if (++RI > arg_size) + break; + + SaveSize += SlotSize; + +#if 1 + BuildMI(MBB, MBBI, DL, TII.get(X86::PUSH64r)) + .addReg(Reg) + .setMIFlag(MachineInstr::FrameSetup); +#else + // MOV64mr Reg, -SaveSize(%rbp) + addRegOffset(BuildMI(MBB, MBBI, DL, TII.get(X86::MOV64mr)), + FramePtr, true, -SaveSize) + .addReg(Reg) + .setMIFlag(MachineInstr::FrameSetup); +#endif + } + + StackSize += SaveSize; +...

...n, we just skip over instructions without a DebugLoc: void CodeViewDebug::beginInstruction(const MachineInstr *MI) { DebugHandlerBase::beginInstruction(MI); // Ignore DBG_VALUE locations and function prologue. if (!Asm || !CurFn || MI->isDebugValue() || MI->getFlag(MachineInstr::FrameSetup)) return; DebugLoc DL = MI->getDebugLoc(); if (DL == PrevInstLoc || !DL) return; maybeRecordLocation(DL, Asm->MF); } Seems reasonable to extend the condition with ' || DL->getLine() == 0'. I'm not aware of a good way to say "this instruction is not associate...

...R2 %R3 %R4 %R5 %R6 %R7 %R8 %R9 %R10 %R11 %LR %D8 %D9 %D10 %D11 %D12 %D13 %D14 %D15 %SP<def> = STMDB_UPD %SP, pred:14, pred:%noreg, %R4<kill>, %R5<kill>, %R6<kill>, %R7<kill>, %R8<kill>, %R9<kill>, %R10<kill>, %R11<kill>, %LR<kill>; flags: FrameSetup %SP<def> = VSTMDDB_UPD %SP, pred:14, pred:%noreg, %D8<kill>, %D9<kill>, %D10<kill>, %D11<kill>, %D12<kill>, %D13<kill>, %D14<kill>, %D15<kill>; flags: FrameSetup ... %SP<def> = LDMIA_RET %SP, pred:14, pred:%noreg, %R4<def>, %R5&l...

...strInfo &TII = *Fn.getTarget().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() == FrameS...

...Needed = true; } } else if (STI.isTargetCygMing()) StackProbeSymbol = "_alloca"; @@ -657,15 +655,15 @@ void X86FrameLowering::emitPrologue(MachineFunction &MF) const { .addReg(X86::EFLAGS, RegState::Define | RegState::Implicit) .setMIFlag(MachineInstr::FrameSetup); - // MSVC x64's __chkstk does not adjust %rsp itself. - // It also does not clobber %rax so we can reuse it when adjusting %rsp. - if (isSPUpdateNeeded) { + if (Is64Bit) { + // MSVC x64's __chkstk and cygwin/mingw's ___chkstk_ms do not adjust %rsp + // themself...

Hi Anton, You're right it fails with a different message with llc 3.0. Anyway thanks for your help. Best Regards Seb > -----Original Message----- > From: Anton Korobeynikov [mailto:anton at korobeynikov.info] > Sent: Monday, June 25, 2012 3:39 PM > To: Sebastien DELDON-GNB > Cc: LLVMdev at cs.uiuc.edu; Rotem, Nadav > Subject: Re: RE : [LLVMdev] Is llc broken for Cortex-A9

Hi, I'd like to submit a patch to match the clang patch on the front end. http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140414/103257.html The front end doesn't need this patch to work but it's still important. This is mostly based on work done by kai from redstar.de Could I get some feedback on this? I'm not sure if the emitting of the register names will effect

...th better alias information. I have created a code which adds marking these spill instructions to the register allocators of llvm. In my implementation spills are marked into spill Machine instructions with MIFlag, adding there a flag bit for spills (currently there is only one flag bit, "FrameSetup" which is only used by x86 backend) My implementation requires just one 9-line function to VirtRegMap class, and a single call to that function in all register allocators. Does this sound reasonable/is there hope of getting this patch through to llvm 3.0 even though currently it only helps...