search for: isloadfromstackslot

...; The register allocator (rewriter to be exact) > will clear the subreg field when substituting > the allocated physical register. Speaking of the rewriter, I've had some problems recently where the rewriter replaces the last of the three load instructions with a COPY instruction because isLoadFromStackSlot() returns the same frame index for all three load. For example, load a.l, <fi#n>, 0 load a.l, <fi#n>, 0 load a.h <fi#n>, 1 ===> load a.h, <fi#n>, 1 load a.e <fi#n>, 3 move a.e, a.l I quickly hacked around the problem by returning a frame in...

On Jul 21, 2010, at 7:44 AM, Ken Dyck wrote: > Speaking of the rewriter, I've had some problems recently where the > rewriter replaces the last of the three load instructions with a COPY > instruction because isLoadFromStackSlot() returns the same frame index > for all three load. For example, > > load a.l, <fi#n>, 0 load a.l, <fi#n>, 0 > load a.h <fi#n>, 1 ===> load a.h, <fi#n>, 1 > load a.e <fi#n>, 3 move a.e, a.l > > I quickly hacked around the...

...010 11:21 AM, Jakob Stoklund Olesen wrote: > > On Jul 21, 2010, at 7:44 AM, Ken Dyck wrote: > > Speaking of the rewriter, I've had some > problems recently where the > > rewriter replaces the last of the three > load instructions with a COPY > > instruction because isLoadFromStackSlot() > returns the same frame index > > for all three load. For example, > > > > load a.l, <fi#n>, 0 load a.l, > <fi#n>, 0 > > load a.h <fi#n>, 1 ===> load a.h, > <fi#n>, 1 > > load a.e <fi#n>, 3 move a.e, a.l...

...TargetRegisterInfo::getFrameRegister looks great, please commit it separately. + /// hasLoadFromStackSlot - If the specified machine instruction is a + /// direct load from a stack slot, return true along with the + /// FrameIndex of the loaded stack slot. If not, return false. + /// Unlike isLoadFromStackSlot, this returns true for any + /// instructions that loads from the stack. This comment is contradictory. It returns true if it is a "direct load" but "returns true for any instructions that loads". likewise with the comment on hasStoreToStackSlot. Would it make sense for...

...his should be synthesizable from the DebugLoc on the instruction in the asm printer, no need to redundantly encode it into the comment field. > - Tag instructions as register spills or reloads. I'm not sure what this means exactly, but would it be sufficient for the asmprinter to use isLoadFromStackSlot and print this if the FI is a spill slot? > - Tag instructions with an ID of the tblgen pattern that generated > them. This > is super useful for debugging. this would also be really nice :). This can be generated by the asm printer as well. > - Tag instructions as top-of-lo...

Attached is a patch to print asm comments for spill information. We've discussed the mechanisms before but I wanted to run the patch by everyone before I start to commit pieces. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: spillcomments.patch Type: text/x-diff Size: 58930 bytes Desc: not available URL:

On Monday 13 July 2009 11:40, Chris Lattner wrote: > > - Tag instructions as register spills or reloads. > > I'm not sure what this means exactly, but would it be sufficient for > the asmprinter to use isLoadFromStackSlot and print this if the FI is > a spill slot? How does one know if the FI is a spill slot? -Dave

On Sunday 12 July 2009 18:56, Chris Lattner wrote: > On Jul 10, 2009, at 3:05 PM, David Greene wrote: > > Here's the first of several patches to get comments into asm > > output. This one > > adds comment information to MachineInstructions and outputs it in the > > generated AsmPrinters. This includes TableGen work to trigger the > > comment > > output

...ter looks > great, please commit it separately. Will do. > + /// hasLoadFromStackSlot - If the specified machine instruction is a > + /// direct load from a stack slot, return true along with the > + /// FrameIndex of the loaded stack slot. If not, return false. > + /// Unlike isLoadFromStackSlot, this returns true for any > + /// instructions that loads from the stack. > > This comment is contradictory. It returns true if it is a "direct > load" but "returns true for any instructions that loads". likewise Cut & paste error. :) > with the comment...

Hi, I would like to query the X86InstrInfo tables to determine if a given opcode is a load or store from stack. I see functions isFrameLoadOpcode and isFrameStoreOpcode in lib/Target/X86/X86InstrInfo.cpp that would provide the functionality I am looking for. However, these functions are static. What is the recommended way to perform such queries for a MachineInstr - short of replicating the

...to. http://llvm.org/docs/CodingStandards.html#doxygen-use-in-documentation-comments + BuildMI(MBB, I, I->getDebugLoc(), TII->get(Tile::ADD) + ,I->getOperand(0).getReg()) + .addReg(Tile::ZERO) + .addReg(src_sp); +unsigned TileInstrInfo:: +isLoadFromStackSlot(const MachineInstr *MI, int &FrameIndex) const You have some weird formatting here and there. You could try clang-format to pretty-print your code automatically. The patch is also missing documentation bits. At the very least, a paragraph for ReleaseNotes. + // save lr to caller's s...

...ards.html#doxygen-use-in-documentation-comments > > + BuildMI(MBB, I, I->getDebugLoc(), TII->get(Tile::ADD) > + ,I->getOperand(0).getReg()) > + .addReg(Tile::ZERO) > + .addReg(src_sp); > > +unsigned TileInstrInfo:: > +isLoadFromStackSlot(const MachineInstr *MI, int &FrameIndex) const > > You have some weird formatting here and there. You could try > clang-format to pretty-print your code automatically. > > The patch is also missing documentation bits. At the very least, a > paragraph for ReleaseNotes. > &...

On 03/01/2013 10:42 PM, Hal Finkel wrote: > > As some of the llvm modules are in active development, for example MC > Layer, we want to return code to community repository first, so that > it will be easy to keep pace with llvm main tree. > I think this makes sense; but my impression is that the community will want a clear idea that this will be maintained and improved for the

...g to submit our line number stuff anyway (it's too much of a hack) but we would like the comment infrastructure to be there. > > - Tag instructions as register spills or reloads. > > I'm not sure what this means exactly, but would it be sufficient for > the asmprinter to use isLoadFromStackSlot and print this if the FI is > a spill slot? Maybe. I'm not sure what information is available here. The other thing this code does is tag it as a vector or scalar spill/reload. Synthesizing that might be trickier as you have to take the opcode into account. It's a lot of work, at th...

On Jul 13, 2009, at 11:47 AM, David Greene wrote: > On Monday 13 July 2009 11:40, Chris Lattner wrote: > >>> - Tag instructions as register spills or reloads. >> >> I'm not sure what this means exactly, but would it be sufficient for >> the asmprinter to use isLoadFromStackSlot and print this if the FI is >> a spill slot? > > How does one know if the FI is a spill slot? We don't currently track this in MachineFrameInfo, but it would be easy (and cheap) to add. -Chris

On Sep 14, 2009, at 10:34 AM, David Greene wrote: > On Monday 14 September 2009 12:32, David Greene wrote: > > >>> The Offset->FrameIndex mapping seems rather heavy-weight, as >>> >>> any expense is incurred even when AsmVerbose is off. Would it >>> >>> be possible to use MachineMemOperands instead? In theory, >>> >>>

On Jul 20, 2010, at 10:57 AM, Ken Dyck wrote: > Does anybody have any tips for generating spills/reloads for large > non-vector registers? > > I'm working on a back end for a DSP architecture that has accumulator > registers that are too large to be spilled or reloaded with a single > instruction. All of their bits can be accessed in word-size chunks via > three

...ngStandards.html#doxygen-use-in-documentation-comments >> >> >> + BuildMI(MBB, I, I->getDebugLoc(), TII->get(Tile::ADD) >> + ,I->getOperand(0).getReg()) >> + .addReg(Tile::ZERO) >> + .addReg(src_sp); >> >> +unsigned TileInstrInfo:: >> +isLoadFromStackSlot(const MachineInstr *MI, int &FrameIndex) const >> >> You have some weird formatting here and there. You could try >> clang-format to pretty-print your code automatically. >> >> The patch is also missing documentation bits. At the very least, a >> paragraph fo...

Does anybody have any tips for generating spills/reloads for large non-vector registers? I'm working on a back end for a DSP architecture that has accumulator registers that are too large to be spilled or reloaded with a single instruction. All of their bits can be accessed in word-size chunks via three sub-registers (low, high, and ext). So loading or storing one requires three instructions:

Hi, I am debugging private backend and faced interesting problem: sometimes spill hoisting creates double stores. (some output from -debug-only=regalloc). First hoisting: Checking redundant spills for 0 at 16r in %vreg19 [16r,144B:0)[144B,240B:1)[240B,280r:2)[296r,416B:3)[416B,456r:4)[472r,592B:5) 0 at 16r 1 at 144B-phi 2 at 240B-phi 3 at 296r 4 at 416B-phi 5 at 472r Merged to stack int: SS#0