similar to: [LLVMdev] Coalescing and VNInfo

On Tuesday 25 September 2007 10:49, David Greene wrote: > I've hit a bug in a refactored version of coalescing and I'm trying to > understand what is going on. In particular, I'm curious about this > line in SimpleRegisterCoalescing.cpp: > > 00710 LHSValsDefinedFromRHS[VNI] = > RHS.getLiveRangeContaining(VNI->def-1)->valno; > > Why VNI->def-1?

LLVM is assuming this: struct InstrSlots { enum { LOAD = 0, USE = 1, DEF = 2, STORE = 3, NUM = 4 }; So VNI->def is always modulo 2. For coalescing, it's checking if the RHS is live at the "use" cycle. So it's checking VNI->def-1. Evan On Sep 25, 2007, at 8:55 AM, David Greene wrote: > On Tuesday

On Tuesday 25 September 2007 12:25, Evan Cheng wrote: > LLVM is assuming this: > struct InstrSlots { > enum { > LOAD = 0, > USE = 1, > DEF = 2, > STORE = 3, > NUM = 4 > }; > > So VNI->def is always modulo 2. For coalescing, it's checking if the > RHS is live at the "use"

On Tuesday 25 September 2007 13:28, David Greene wrote: > > So VNI->def is always modulo 2. For coalescing, it's checking if the > > RHS is live at the "use" cycle. So it's checking VNI->def-1. > > But why is it looking at a use slot in this case, where the coalescer is > trying to get the vaue number for the def of the RHS register so it can > use

Hi Jonas, Thanks for your patience. After spending some time looking at the additional output you gave me, I agree that your fix is the right one. I was worried that this problem may arise because we were spilling not real user, but in fact what I thought was the problem is an optimization we could do :). See my comments inlined for a few nitpicks before you commit. Thanks again, -Quentin On

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 =

Hi Quentin, I have tried to find a test case for an official target, but failed. It seems to be a rare case. To do it, I added the 'else' clause in the following: ... if (VNI->def == OrigVNI->def) { DEBUG(dbgs() << "orig phi value\n"); SVI->second.DefByOrigPHI = true; SVI->second.AllDefsAreReloads = false; propagateSiblingValue(SVI); continue;

Hi Quentin, I have rerun the test case on a recent commit, so the numbers have changed. There are also now a few more basic blocks very small basic blocks in the function, and therefore there are some slight differences. I tried to go back to earlier commits, without success for some reason... This is however very similar, except that there becomes two COPYs back to sibling value after the loop.

Hi, I have encountered a test case where InlineSpiller generates bad code. A register is reloaded but never spilled, and I suspect a bug in InlineSpiller. A register is live over a loop that also have two inner loops. It is not used or defined over the inner loops. It is split into two sibling registers, where one covers just the inner loops interval, which is then spilled. In spill(),

Hello LLVM Developers, We are working on extending currently available register rematerialization to include cases where sequence of multiple instructions is required to rematerialize a value. We had a discussion on this in community mailing list and link is here: http://lists.llvm.org/pipermail/llvm-dev/2016-September/subject.html#104777 >From the above discussion and studying the code we

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

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >> Are all of those sibling values guaranteed to ultimately derive from the >> same def, in the sense that they can be traced through copies, phis, >> etc. back to a single instruction? > > They are known the all come from the same value in the original live range from before live range splitting. Ok, that's

I've been playing around with spillers and found that the SimpleSpiller fails badly on a particular code. The problem arises because SimpleSpiller does the test VRM.isAssignedReg(virtReg) which is implemented as: 00183 bool isAssignedReg(unsigned virtReg) const { 00184 if (getStackSlot(virtReg) == NO_STACK_SLOT && 00185 getReMatId(virtReg) == NO_STACK_SLOT)

The buildbot @ http://lab.llvm.org:8011/builders/llvm-gcc-i686-pc-linux-gnu-cross-arm-eabi-soft-float/builds/850 is failing with following assertion failure. Is it possible for someone to collect a preprocessed source file and file a PR ? Thanks, - Devang cc1: /opt/buildslave/osuosl/slave/llvm-gcc-i686-pc-linux-gnu-cross-arm-eabi-soft-float/llvm.src/lib/CodeGen/LiveIntervalAnalysis.cpp:713: bool

Hi all, Mikael reported a machine verification failure in his out-of-tree target with the MachineCopyPropagation changes to forward registers (which is currently reverted). The verification in question is: *** Bad machine code: Multiple connected components in live interval *** - function: utils_la_suite_matmul_ref - interval: %vreg77

Hi, It looks like LiveIntervals::addIntervalsForSpills does not update all of the LiveIntervals infos quite correctly. In particular, if a live interval L is defined by Reg<-Reg copy instructions whose srcReg is later spilled by the addIntervalsForSpills() function, its VNInfo information is not updated in a proper way. It still points to the same MachineInstr as before, even though the

Hello! I'd like to use PriorityInheritance option, despite it is still experimental. (Why it could be experimental, when it looks quite simple feature, no?) But this option doesn't change the TOS field of outgoing UDP packet. I just do tcpdump on outgoing interface from vty1: $ sudo tcpdump -vni eth0 udp dst port 655 And from vty2 I do ping with setting of tos field to EF(0xb8). $

Devang, I see the cause for confusion. Your message from this morning was specifically referring to this assert: Assertion `ExtVNI == VNI && "Unexpected existing value number"' failed. That assertion was fixed in the r144547. The PR shows this assert: Assertion failed: (isMetadata() && "Wrong MachineOperand accessor"), function Bisect fails until the

In LLVM 3.1, given a VNInfo, how do I get the range information for that value? I've tried looking at the MachineInstr at the def point, getting its defined register and looking at LiveIntervals to get an interval for the register, but that doesn't always return something sane. I'm in the middle of InlineSpiller so LiveRangeEdit is in play. Thanks for your help!

Hello Devang, Please find attached the preprocessed source file and the LLVM bitecode. Hope this will help. Thanks Galina On Mon, Nov 14, 2011 at 9:48 AM, Devang Patel <dpatel at apple.com> wrote: > The buildbot > @ http://lab.llvm.org:8011/builders/llvm-gcc-i686-pc-linux-gnu-cross-arm-eabi-soft-float/builds/850 > is failing with following assertion failure. Is it possible for