similar to: RFC: Setting MachineInstr flags through storeRegToStackSlot

> -----Original Message----- > From: mbraun at apple.com [mailto:mbraun at apple.com] > Sent: Friday, February 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

Consider this example: --- ex.ll --- declare void @bar() ; Function Attrs: nounwind optsize define void @main() { entry: %hin = alloca [256 x i32], align 4 %xin = alloca [256 x i32], align 4 call void @bar() ret void } ------------- Freshly built llc: llc -O2 -march=x86 < ex.ll -print-before-all # *** IR Dump Before Prologue/Epilogue Insertion & Frame Finalization ***: #

Hi All, I'm dealing with a problem where the spill/restore instructions inserted during scavenging span an adjustment of the SP/FP register. The result is that despite the base register (SP/FP) being changed between the spill and the restore, both store and load use the same immediate offset. I see code in the PEI (replaceFrameIndices) that is supposed to track the SP/FP adjustment:

The code has changed a lot over the years. Looks like at some point of time the assumption was broken. calculateCallsInformation() may have eliminated the pseudo set up instructions already. // If call frames are not being included as part of the stack frame, and

I started to implement inlining of the stack probe function based on Microsoft's inlined stack probes in https://github.com/Microsoft/llvm/tree/MS. Do we know why the stack pointer cannot be updated in a loop (which results in ideal code)? I noticed that was commented in Microsoft's code. I suspect this is due to debug or unwinding information, since it is allowed on Windows x86-32. I

Thanks, I'll look into that. Still, the case where the function does not call anything remains---in such a situation there are no ADJCALLSTACK pseudos, so regardless of what that function you pointed at does, there won't be any target-independent information about the SP adjustment by the time the frame index elimination runs. Would it make sense to have ADJCALLSTACK pseudos every

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 replaceFrameIndices are run. Evan On Sep 25, 2013, at 8:57 AM, Krzysztof

Hi, I'm implementing storeRegToStackSlot() and, in order to store some specific registers (floating point regs and address regs) I've to copy them to more standard regs and copy these last ones to the slot. I tried to generate instructions that use physical registers, but by doing that I overwrote registers already assigned by the register allocator. Is it possible to use virtual registers

On Jan 23, 2009, at 3:28 AM, Mondada Gabriele wrote: > Hi, > I'm implementing storeRegToStackSlot() and, in order to store some > specific registers (floating point regs and address regs) I've to > copy them to more standard regs and copy these last ones to the slot. > I tried to generate instructions that use physical registers, but by > doing that I overwrote

Hi, I found 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

Dan Gohman a écrit : > On Jan 23, 2009, at 3:28 AM, Mondada Gabriele wrote: > > >> Hi, >> I'm implementing storeRegToStackSlot() and, in order to store some >> specific registers (floating point regs and address regs) I've to >> copy them to more standard regs and copy these last ones to the slot. >> I tried to generate instructions that use

ola, ive been looking at adding support for an -msave-args option for use on x86_64. the short explanation of it is that it makes x86_64 function prologues store their register arguments on the stack. the purpose of this is to make the arguments trivially accessible for things like stack traces with arguments. as per https://blogs.oracle.com/sherrym/entry/obtaining_function_arguments_on_amd64,

In our case, storeRegToStackSlot, loadRegFromStackSlot clobbers some other physical register which may be holding a live value used somewhere else. How do I make regalloc aware so that it saves the value before storeRegToStackSlot and make it available again at the point of earlier use? TIA, Sanjiv -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Oct 22, 2008, at 11:09 AM, Sanjiv.Gupta at microchip.com wrote: > In our case, storeRegToStackSlot, loadRegFromStackSlot clobbers some > other physical register which may be holding a live value used > somewhere else. How do I make regalloc aware so that it saves the > value before storeRegToStackSlot and make it available again at the > point of earlier use? >

On Thu, 2008-10-23 at 11:17 -0700, Evan Cheng wrote: > > On Oct 22, 2008, at 11:09 AM, Sanjiv.Gupta at microchip.com wrote: > > > In our case, storeRegToStackSlot, loadRegFromStackSlot clobbers some > > other physical register which may be holding a live value used > > somewhere else. How do I make regalloc aware so that it saves the > > value before

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

Hi All. I'm writing storeRegToStackSlot and loadFromStackSlot function for my Target. This Target can store/load one byte (not all word) from FrameIndex. If I need to store 16 bit register I will must to split it to two instruction like this: BuildMI(MBB, MI, dl, get(Z80::LD8xmr)) .addFrameIndex(FrameIndex).addImm(0) .addReg(SrcReg, 0, Z80::subreg_lo); BuildMI(MBB, MI, dl,

Hi Lang. Thank you. I added pseudo-instructions for spill/reloads and expanded it in expandPostRAPseudo. Regards, Dmitriy. 04.03.2013 8:24, Lang Hames wrote: > Hi Dmitriy, > > As you've seen our current spill code assumes that spill/reloads are > single instructions. I think the best way to work around this is to > introduce load/store pseudo-instructions and expand these

Chris Lattner wrote: > On Sat, 13 May 2006, Vladimir Prus wrote: >> in LLVM CVS the afore-mentioned function has 'const TargetRegisterClass*' >> parameter, that is not documented. >> >> Can somebody explain what does it mean? > > Basically, it gives the target more information about the spill. In > particular, it specifies the register class to use

Hi Dmitriy, As you've seen our current spill code assumes that spill/reloads are single instructions. I think the best way to work around this is to introduce load/store pseudo-instructions and expand these after register allocation. Cheers, Lang. On Sat, Feb 23, 2013 at 12:15 AM, Dmitriy Limonov <earl at excluzive.ws> wrote: > Hi All. > > I'm writing