search for: valnos

...is a phi which was part of the original LI, then OrigVNI must be that PHI. This is not the case here. The algorithm has iterated past OrigVNI and VNI is at this point a phi that was part of the original LI, which is the copy source of OrigVNI. Or, it is assumed that splitting is always done at PHI ValNos somehow, and not as in this case, by a COPY of a PHI ValNo. I would very much appreciate assistance in resolving this problem. As explained above, it is not clear to me why this error occurs, or what is the appropriate fix. I can provide more details if needed for some reason. Best regards, Jona...

...is a phi which was part of the original LI, then OrigVNI must be that PHI. This is not the case here. The algorithm has iterated past OrigVNI and VNI is at this point a phi that was part of the original LI, which is the copy source of OrigVNI. Or, it is assumed that splitting is always done at PHI ValNos somehow, and not as in this case, by a COPY of a PHI ValNo. I would very much appreciate assistance in resolving this problem. As explained above, it is not clear to me why this error occurs, or what is the appropriate fix. I can provide more details if needed for some reason. Best regards, Jona...

...t'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) { ReplacedValNos.push_back(IP[-1].va...

...uestion 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 the inner if to: > if (IP[-1].valno != LH...

...is a phi which was part of the original LI, then OrigVNI must be that PHI. This is not the case here. The algorithm has iterated past OrigVNI and VNI is at this point a phi that was part of the original LI, which is the copy source of OrigVNI. Or, it is assumed that splitting is always done at PHI ValNos somehow, and not as in this case, by a COPY of a PHI ValNo. I would very much appreciate assistance in resolving this problem. As explained above, it is not clear to me why this error occurs, or what is the appropriate fix. I can provide more details if needed for some reason. Best regards, Jona...

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(),

...copy register, and kills that are not > in the liverange data structure. LiveInterval has these members: typedef SmallVector<LiveRange,4> Ranges; typedef SmallVector<VNInfo*,4> VNInfoList; Ranges ranges; // the ranges in which this register is live VNInfoList valnos; // value#'s Since LiveRance contains: struct LiveRange { unsigned start; // Start point of the interval (inclusive) unsigned end; // End point of the interval (exclusive) VNInfo *valno; // identifier for the value contained in this interval. I'm wondering what the...

...he original LI, then OrigVNI must be that PHI. This is not the case here. >> The algorithm has iterated past OrigVNI and VNI is at this point a phi that was part of the original LI, which is the copy source of OrigVNI. >> >> Or, it is assumed that splitting is always done at PHI ValNos somehow, and not as in this case, by a COPY of a PHI ValNo. >> >> I would very much appreciate assistance in resolving this problem. As explained above, it is not clear to me why this error occurs, or what is the appropriate fix. I can provide more details if needed for some reason. &...

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<kill> 320 %reg1054 = MOV64rr

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>

...rCoalescing.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(), Start); // If the start of this range overlaps with an existing...

Hi Jan, > 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 improvement is wonderful! ... > In any case, the patch is attached if

...2_e32 1, implicit $exec # End machine code for function multiple_connected_components_dead. *** Bad machine code: Multiple connected components in live interval *** - function: multiple_connected_components_dead - interval: %0 [16r,16d:1)[32r,32d:0) 0 at 32r 1 at 16r weight:0.000000e+00 0: valnos 0 1: valnos 1 LLVM ERROR: Found 1 machine code errors. What is the problem here? -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190909/6e9835b7/attachment.html>

...gt; 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 the inner...

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

Thanks. More questions :-) /// Information about how the value is assigned. - LocInfo HTP : 7; + LocInfo HTP : 6; Do you know why this change is needed? Are we running out of bits? - NeededStackSize = 4; - break; - case MVT::i64: - case MVT::f64: - if (firstGPR < 3) - NeededGPRs = 2; - else if (firstGPR == 3) { - NeededGPRs = 1; - NeededStackSize = 4; -

...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(), Start); > // If the start of this ran...

On Mon, Feb 16, 2009 at 11:00 AM, Evan Cheng <evan.cheng at apple.com> wrote: > /// Information about how the value is assigned. > - LocInfo HTP : 7; > + LocInfo HTP : 6; > > Do you know why this change is needed? Are we running out of bits? HTP was't using all of these bits. I needed the hasCustom bit to come from somewhere unless we wanted to grow this struct, so I