search for: valno

...ecking 1 phi-defs, and 2 non-phi/orig defs %vreg87:7 at 2276r: copy of %vreg86:0 at 1396r kill=1 traced to: spill %vreg86:0 at 1396r all-reloads kill deps[ 7 at 2276r ] Merged spilled regs: SS#1 [1396r,2276r:0) 0 at x I am guessing that traceSiblingValue() should have stopped at a PHI ValNo by recognizing it as 'original', meaning it was not inserted by splitting. It does not although it is clear that this PHI ValNo is part of OrigLI. This is how it looked, roughly: Original LiveInterval: 5 0 --- inner loops ---...

..., 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; } // check if the valno is actually an orig PHI, but is not OrigVNI else { LiveInterval &OrigLI = LIS.getInterval(Original); VNInfo *OrigVNI_curr = OrigLI.getVNInfoAt(VNI->def); if (OrigVNI_curr->def == VNI->def) assert(0 && "OrigLI contained VNI which was a PHI, but not OrigVNI!")...

Hrm, I see a bug here. Let's say the liverange in question is [13,20) and the interval it's being merged to is something like this: [1, 4), [10, 15) IP = std::upper_bound(IP, end(), Start); if (IP != begin() && IP[-1].end > Start) { if (IP->valno != LHSValNo) { ReplacedValNos.push_back(IP->valno); IP->valno = LHSValNo; // Update val#. } IP is end() and we would be pushing junk into ReplacedValNos. Is this what you saw? I wonder if the fix should be changing the inner if to: if (IP[-1].valno != LHSValNo)...

...a bug here. Let's say the liverange in question is [13,20) > and the interval it's being merged to is something like this: [1, 4), > [10, 15) > > IP = std::upper_bound(IP, end(), Start); > if (IP != begin() && IP[-1].end > Start) { > if (IP->valno != LHSValNo) { > ReplacedValNos.push_back(IP->valno); > IP->valno = LHSValNo; // Update val#. > } > > IP is end() and we would be pushing junk into ReplacedValNos. Is this > what you saw? Yep, exactly. > I wonder if the fix should be changing...

...1 %vreg122:5 at 1472B: split phi value, checking 2 phi-defs, and 3 non-phi/orig defs // WRONG: the phi value was part of %vreg111 interval, see above. The non-phi/defs to check are the sibling COPYs after the inner loops from %vreg121 to %vreg122 (@2948, @2968), and the identity COPY from valno 5 to 6 @1520 for %vreg122. 3. Vreg122:5 @1472 is the beginning of a basic block. It was there all along, first in %vreg111, and then in %vreg122. %vreg111 gets split two blocks further down @1764. Outer loop { BB2: ... BB15: ... BB3: //joining BB2 and BB15 @1472 // PHI value that should ha...

On Wednesday 30 January 2008 02:02, Evan Cheng wrote: > AFAIK std::upper_bound() would not return end(), right? Yes, it can return end(). In fact that's exactly what I'm seeing. std::upper_bound is just binary search and returns where the element should be inserted to retain ordering. So for example, if my iterator range is over: 1 2 3 4 5 and I call std::upper_bound(begin(),

...not using the current default llvm coalescer. It may be that I'm updating dataflow information incorrectly. I'll check on that. > > If so, then isn't LiveInterval::Ranges and LiveInterval::VNInfoList > > redundant? > > What's in VNInfoList that's not in the valno member of the Ranges > > elements, > > and vice-versa? > > I am not sure if I understand your question. Multiple liveranges can > be of the same val#. Each VNInfo contains definition (if not > containing a phi merge, etc.), copy register, and kills that are not > in the l...

...472B: split phi value, checking 2 phi-defs, and 3 non-phi/orig defs // WRONG: the phi value was part of %vreg111 interval, see above. >> >> The non-phi/defs to check are the sibling COPYs after the inner loops from %vreg121 to %vreg122 (@2948, @2968), and the identity COPY from valno 5 to 6 @1520 for %vreg122. >> >> 3. >> Vreg122:5 @1472 is the beginning of a basic block. It was there all along, first in %vreg111, and then in %vreg122. %vreg111 gets split two blocks further down @1764. >> >> Outer loop >> { >> >> BB2: >&g...

I had been assuming that give a LiveRange a, a.valno->def, if valid, would be the same as a.start. But this is apparently not always the case. For example: Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35) 308 %reg1051 = MOV64rr %reg1227<kill> 312 %reg1052 = MOV64rr %reg1228<kill> 316 %reg1053 = MOV64rr %reg1229<k...

On Jan 16, 2008, at 11:49 AM, David Greene wrote: > I had been assuming that give a LiveRange a, a.valno->def, if > valid, would be the same as a.start. But this is apparently not > always the case. For example: > > Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35) > 308 %reg1051 = MOV64rr %reg1227<kill> > 312 %reg1052 = MOV64rr %reg1228<kill> > 316...

...s live ranges of aliased registers (around line 473 of SimpleRegisterCoalescing.cpp). There's a call to MergeValueInAsValue at line 50. MergeValueInAsValue has this code: void LiveInterval::MergeValueInAsValue(const LiveInterval &RHS, const VNInfo *RHSValNo, VNInfo *LHSValNo) { SmallVector<VNInfo*, 4> ReplacedValNos; iterator IP = begin(); for (const_iterator I = RHS.begin(), E = RHS.end(); I != E; ++I) { if (I->valno != RHSValNo) continue; unsigned Start = I->start, End = I->end; IP = std::upper_bound(IP, end()...

...BB); ... > diff --git a/lib/Bitcode/Reader/BitcodeReader.h b/lib/Bitcode/Reader/BitcodeReader.h > index e7c4e94..249d723 100644 > --- a/lib/Bitcode/Reader/BitcodeReader.h > +++ b/lib/Bitcode/Reader/BitcodeReader.h ... > @@ -260,14 +274,30 @@ private: > ResVal = getFnValueByID(ValNo, getTypeByID(TypeNo)); > return ResVal == 0; > } > + /// getValue - Read a value out of the specified record from slot 'Slot'. > + /// Increment Slot past the number of slots used in the record. > + /// Return true on failure. > bool getValue(SmallVector<u...

...are 2 dead defs of the same register: --- name: multiple_connected_compnents_dead tracksRegLiveness: true body: | bb.0: dead %0:vgpr_32 = V_MOV_B32_e32 0, implicit $exec dead %0:vgpr_32 = V_MOV_B32_e32 1, implicit $exec ... The live intervals look OK to me with 1 valno per instruction, for the life of the instruction like I would expect. The verifier does not like it however: $ llc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx906 -verify-machineinstrs -run-pass=machine-scheduler -o - -verify-misched foo.mir # Before machine scheduling. ********** INTERVALS ********** %0...

...say the liverange in question is [13,20) >> and the interval it's being merged to is something like this: [1, 4), >> [10, 15) >> >> IP = std::upper_bound(IP, end(), Start); >> if (IP != begin() && IP[-1].end > Start) { >> if (IP->valno != LHSValNo) { >> ReplacedValNos.push_back(IP->valno); >> IP->valno = LHSValNo; // Update val#. >> } >> >> IP is end() and we would be pushing junk into ReplacedValNos. Is this >> what you saw? > > Yep, exactly. > >>...

Hi all, I've been looking into how to make llvm bitcode files smaller. There is one simple change that appears to shrink linked bitcode files by about 15%. See this spreadsheet for some rough data: https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E The change is in how operand ids are encoded in bitcode files. Rather than use an "absolute

...al *** Having looked at what this might mean, it seems that ConnectedVNInfoEqClasses::Classify() was called on the LI in question by the verifier, and that it returned two equivalence classes, instead of just one, which is demanded by the verifier. Does this mean that there should never be any ValNos in a LiveInterval that are not connected? In other words should such an LI never exist, but rather two different LIs? I have tried to run this on in-tree targets, but unfortunately they did not reproduce the condition. I will therefore try to explain: The options to llc are -optimize-regalloc...

...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 [192r,208B:0)[208B,260r:1)[312r,364r:2)[380r,464B:3) 0 at 192r 1 at 208B-phi 2 at 312r 3 at 380r 0: valnos 0 1 3 1: valnos 2 In this particular case, I believe that it is the greedy allocator that is creating the multiple components in the %vreg77 live interval. If you look at the attached debug dump file, just after the greedy allocator runs, the segment of %vreg77 from the def at 312B to the use...

...bits? - NeededStackSize = 4; - break; - case MVT::i64: - case MVT::f64: - if (firstGPR < 3) - NeededGPRs = 2; - else if (firstGPR == 3) { - NeededGPRs = 1; - NeededStackSize = 4; - } else - NeededStackSize = 8; + State.addLoc(CCValAssign::getCustomMem(ValNo, ValVT, + State.AllocateStack(4, 4), + MVT::i32, LocInfo)); + return true; // we handled it Your change isn't handling the "NeededStackSize = 8" case. ++ static const unsigned HiRegList[] =...

...(around line 473 of SimpleRegisterCoalescing.cpp). > > There's a call to MergeValueInAsValue at line 50. > MergeValueInAsValue has > this code: > > void LiveInterval::MergeValueInAsValue(const LiveInterval &RHS, > const VNInfo *RHSValNo, VNInfo > *LHSValNo) > { > SmallVector<VNInfo*, 4> ReplacedValNos; > iterator IP = begin(); > for (const_iterator I = RHS.begin(), E = RHS.end(); I != E; ++I) { > if (I->valno != RHSValNo) > continue; > unsigned Start = I->start, End = I->end;...

...; - case MVT::i64: > - case MVT::f64: > - if (firstGPR < 3) > - NeededGPRs = 2; > - else if (firstGPR == 3) { > - NeededGPRs = 1; > - NeededStackSize = 4; > - } else > - NeededStackSize = 8; > + State.addLoc(CCValAssign::getCustomMem(ValNo, ValVT, > + State.AllocateStack(4, 4), > + MVT::i32, LocInfo)); > + return true; // we handled it > > Your change isn't handling the "NeededStackSize = 8" case. I believe it is....