search for: spillaroundus

Hi Ryan, > On Mar 14, 2016, at 7:49 AM, Ryan Taylor via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I looked at this again and it appears that while spillAroundUses sets the register as 'dead', there is no checking to see if it's dead in subsequent iterations of the bundle loop. > > Is this intentional? > > On Mon, Mar 7, 2016 at 3:28 PM, Ryan Taylor <ryta1203 at gmail.com <mailto:ryta1203 at gmail.com>> wrote: > Look...

Looks like spillAroundUses is spilling multiple duplicate copies to the stack, for example, with some regs we get 1 storeRegToStack call, for others we get multiple (2-6+) and then these instructions are never eliminated. Looking at spillAroundUses it looks like multiple duplicate COPYs are being generated, why? One for e...

...// This is a dead def. Make sure the instruction knows. MachineInstr *MI = getInstructionFromIndex(Def); assert(MI && "No instruction defining live value"); MI->addRegisterDead(LI.reg, TRI); and the reload after the BUNDLE is introduced by InlineSpiller::spillAroundUses which has determined that the register is live: // Rewrite instruction operands. bool hasLiveDef = false; for (const auto &OpPair : Ops) { MachineOperand &MO = OpPair.first->getOperand(OpPair.second); MO.setReg(NewVReg); if (MO.isUse()) {...

I think I'm getting a bit closer to the problem. I've found that the call to InlineSpiller::foldMemoryOperand() inside InlineSpiller::spillAroundUses() is causing the problems. As a test, I removed that call and with your yesterday's patch I'm not getting any errors at all, the code generated is the same one as with the call. This is happening when InlineSpiller::foldMemoryOperand() returns true, so a very wild guess is that maybe when...

...anyRemat |= reMaterializeFor(LI, MI); } and MachineRegisterInfo::defusechain_instr_iterator::advance seems to skip all def operands for use_bundle_nodbg_iterator since ReturnDefs is false. So it will happily advance past the instruction setting lo16.) Then after the remats it does spillAroundUses %vreg1954 and there I get reload: 5052r %vreg1957<def> = Load40FI <fi#2> rewrite: 5056r %vreg1957:lo16<def> = mv_nimm6_ar16 0 since no remat was inserted before 5056. But noone has stored anything at fi#2 so I end up with *** Bad machine code: Instruction loads from d...

On Jul 15, 2012, at 9:20 AM, Borja Ferrer <borja.ferav at gmail.com> wrote: > Jakob, one more hint, I've placed some asserts around the code you added and noticed that the InlineSpiller::insertReload() function is not being called. > > 2012/7/14 Borja Ferrer <borja.ferav at gmail.com> > Hello Jakob, > > I'm still getting the error, I can give you any other

...tore and one to load. Currently, the loaded reg always has the same class as the stored reg. Because of this limitation, I ran into a problem: the RA would try to assign two Accs to physical regs, but only one is available, and the RA would fail. Line 1290 of InlineSpiller.cpp, inside the function spillAroundUses, says: "// FIXME: Infer regclass from instruction alone" (As opposed to the current behavior of always using the same class as the reg being spilled.) The line refers to this very limitation. It was written in 2010, so we've known about the limitation since the beginning. My RA pat...

...fo is simply lost". In UserValue::insertDebugValue in LiveDebugVariables.cpp if emitFrameIndexDebugValue returns 0 then it adds a DBG_VALUE with the standard operands. However in other places where emitFrameIndexDebugValue is called it appears to removes the debug value (e.g. in InlineSpiller::spillAroundUses()). Should the comment be updated or is the code in LiveDebugVariables.cpp doing the wrong thing? > /jakob -- Richard Osborne | XMOS http://www.xmos.com -------------- next part -------------- A non-text attachment was scrubbed... Name: dbg_value.patch Type: text/x-patch Size: 1166 bytes D...

On Jul 15, 2012, at 4:50 PM, Borja Ferrer <borja.ferav at gmail.com> wrote: > I think I'm getting a bit closer to the problem. I've found that the call to InlineSpiller::foldMemoryOperand() inside InlineSpiller::spillAroundUses() is causing the problems. > As a test, I removed that call and with your yesterday's patch I'm not getting any errors at all, the code generated is the same one as with the call. This is happening when InlineSpiller::foldMemoryOperand() returns true, so a very wild guess is that mayb...

Hi all, I'm tracking down a register allocation problem and I'm trying to understand this piece of code in InlineSpiller::spillAroundUses: // Find the slot index where this instruction reads and writes OldLI. // This is usually the def slot, except for tied early clobbers. SlotIndex Idx = LIS.getInstructionIndex(*MI).getRegSlot(); if (VNInfo *VNI = OldLI.getVNInfoAt(Idx.getRegSlot(true))) if (SlotIndex::isSam...

On Oct 10, 2011, at 10:26 AM, Richard Osborne wrote: > I'm investigating a bug associated with debug information that manifests > itself in the XCore backend (PR11105). I'd like to understand what the > expected behavior of eliminateFrameIndex() is when it is called on a > dbg_value machine instruction. That is up to the target. The TII::emitFrameIndexDebugValue() hook is

I'm investigating a bug associated with debug information that manifests itself in the XCore backend (PR11105). I'd like to understand what the expected behavior of eliminateFrameIndex() is when it is called on a dbg_value machine instruction. Currently the XCore target replaces the frame index with the frame register and sets the next operand to the byte offset from the frame

> On Jun 28, 2017, at 5:10 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Oh wait, vreg1 is indeed used. > Yeah, having a dead flag here sounds wrong. I mean on the instruction itself. On the bundle, that’s debatable. That would fit the semantic “if no side effect you can kill it” (here there is side effect, we define other vregs). > >> On

Hi Quentin, On 08/15/14 19:01, Quentin Colombet wrote: [...] >> The question is: How should true subregister definitions be >> expressed so that they do not interfere with each other? See the >> detailed problem description below. > > We do have a limitation in our current liveness tracking for > sub-register. Therefore, I am not sure that is possible. > >