Displaying 11 results from an estimated 11 matches for "oldindex".
Did you mean:
old_index
2005 Dec 31
0
Question about periodically_call_remote
...on, and subsequent calls go through
next_description:
def index
@description_index = 0
@description = get_current_description
end
# Called by ajax call; renders the partial directly after
# determining next row to show
def next_description
@allrows = find_all
@description_index = params[:oldindex] + 1
# if we''ve shown all, then start over again
if (@description_index > @allrows.length)
@description_index = 0
end
@description = get_current_description
render :partial => ''currentdescription''
end
def get_current_description
@allrows[@descriptio...
2012 Aug 28
5
[LLVMdev] Assert in LiveInterval update
...lotIndex
renumbering:
*** Renumbered SlotIndexes 24-56 ***
So my 48B becomes 56B, so after the update new live ranges look like this:
R2 = [0B,56r:0)[352r,416r:5)...
R3 = [0B,56r:0)[368r,416r:5)...
R4 = [0B,48r:0)[384r,416r:4)...
R5 = [0B,48r:0)[400r,416r:4)...
Then in LiveIntervals::handleMove OldIndex 56B and NewIndex is 32B (also new
after renumbering. But happens to match another old one).
collectRanges for MI figures that it is moving a paired register, and
correctly(?) selects these two ranges to update for %R2:R3
[0B,56r:0)[368r,416r:5)...
[0B,56r:0)[352r,416r:5)...
___BUT____ after the u...
2012 Aug 30
0
[LLVMdev] Assert in LiveInterval update
...Indexes 24-56 ***
>
> So my 48B becomes 56B, so after the update new live ranges look like this:
>
> R2 = [0B,56r:0)[352r,416r:5)...
> R3 = [0B,56r:0)[368r,416r:5)...
> R4 = [0B,48r:0)[384r,416r:4)...
> R5 = [0B,48r:0)[400r,416r:4)...
>
> Then in LiveIntervals::handleMove OldIndex 56B and NewIndex is 32B (also
> new
> after renumbering. But happens to match another old one).
> collectRanges for MI figures that it is moving a paired register, and
> correctly(?) selects these two ranges to update for %R2:R3
>
> [0B,56r:0)[368r,416r:5)...
> [0B,56r:0)[352r,...
2012 Aug 31
2
[LLVMdev] Assert in LiveInterval update
...lotIndex
renumbering:
*** Renumbered SlotIndexes 24-56 ***
So my 48B becomes 56B, so after the update new live ranges look like this:
R2 = [0B,56r:0)[352r,416r:5)...
R3 = [0B,56r:0)[368r,416r:5)...
R4 = [0B,48r:0)[384r,416r:4)...
R5 = [0B,48r:0)[400r,416r:4)...
Then in LiveIntervals::handleMove OldIndex 56B and NewIndex is 32B (also new
after renumbering. But happens to match another old one).
collectRanges for MI figures that it is moving a paired register, and
correctly(?) selects these two ranges to update for %R2:R3
[0B,56r:0)[368r,416r:5)...
[0B,56r:0)[352r,416r:5)...
___BUT____ after the u...
2012 Aug 30
0
[LLVMdev] MC Register mapping question (MCRegUnitIterator )
...24-56 ***
>
> So my 48B becomes 56B, so after the update new live ranges look like
> this:
>
> R2 = [0B,56r:0)[352r,416r:5)...
> R3 = [0B,56r:0)[368r,416r:5)...
> R4 = [0B,48r:0)[384r,416r:4)...
> R5 = [0B,48r:0)[400r,416r:4)...
>
> Then in LiveIntervals::handleMove OldIndex 56B and NewIndex is 32B
> (also new after renumbering. But happens to match another old one).
> collectRanges for MI figures that it is moving a paired register, and
> correctly(?) selects these two ranges to update for %R2:R3
>
> [0B,56r:0)[368r,416r:5)...
> [0B,56r:0)[352r,416r...
2012 Aug 31
0
[LLVMdev] Assert in LiveInterval update
...lotIndex
renumbering:
*** Renumbered SlotIndexes 24-56 ***
So my 48B becomes 56B, so after the update new live ranges look like this:
R2 = [0B,56r:0)[352r,416r:5)...
R3 = [0B,56r:0)[368r,416r:5)...
R4 = [0B,48r:0)[384r,416r:4)...
R5 = [0B,48r:0)[400r,416r:4)...
Then in LiveIntervals::handleMove OldIndex 56B and NewIndex is 32B (also new
after renumbering. But happens to match another old one).
collectRanges for MI figures that it is moving a paired register, and
correctly(?) selects these two ranges to update for %R2:R3
[0B,56r:0)[368r,416r:5)...
[0B,56r:0)[352r,416r:5)...
___BUT____ after the u...
2012 Aug 30
2
[LLVMdev] MC Register mapping question (MCRegUnitIterator )
...becomes 56B, so after the update new live ranges look like
>> this:
>>
>> R2 = [0B,56r:0)[352r,416r:5)...
>> R3 = [0B,56r:0)[368r,416r:5)...
>> R4 = [0B,48r:0)[384r,416r:4)...
>> R5 = [0B,48r:0)[400r,416r:4)...
>>
>> Then in LiveIntervals::handleMove OldIndex 56B and NewIndex is 32B
>> (also new after renumbering. But happens to match another old one).
>> collectRanges for MI figures that it is moving a paired register, and
>> correctly(?) selects these two ranges to update for %R2:R3
>>
>> [0B,56r:0)[368r,416r:5)...
>&g...
2012 Aug 28
0
[LLVMdev] Assert in LiveInterval update
On Aug 28, 2012, at 8:18 AM, Sergei Larin <slarin at codeaurora.org> wrote:
>
> I've described that issue (see below) when you were out of town... I think
> I am getting more context on it. Please take a look...
>
> So, in short, when the new MI scheduler performs move of an instruction, it
> does something like this:
>
> // Move the instruction to its new
2012 Aug 30
0
[LLVMdev] MC Register mapping question (MCRegUnitIterator )
...ve ranges look like
> >> this:
> >>
> >> R2 = [0B,56r:0)[352r,416r:5)...
> >> R3 = [0B,56r:0)[368r,416r:5)...
> >> R4 = [0B,48r:0)[384r,416r:4)...
> >> R5 = [0B,48r:0)[400r,416r:4)...
> >>
> >> Then in LiveIntervals::handleMove OldIndex 56B and NewIndex is 32B
> >> (also new after renumbering. But happens to match another old one).
> >> collectRanges for MI figures that it is moving a paired register,
> and
> >> correctly(?) selects these two ranges to update for %R2:R3
> >>
> >> [0B...
2012 Sep 03
2
[LLVMdev] Assert in LiveInterval update
...Indexes 24-56 ***
>
> So my 48B becomes 56B, so after the update new live ranges look like this:
>
> R2 = [0B,56r:0)[352r,416r:5)...
> R3 = [0B,56r:0)[368r,416r:5)...
> R4 = [0B,48r:0)[384r,416r:4)...
> R5 = [0B,48r:0)[400r,416r:4)...
>
> Then in LiveIntervals::handleMove OldIndex 56B and NewIndex is 32B (also
> new
> after renumbering. But happens to match another old one).
> collectRanges for MI figures that it is moving a paired register, and
> correctly(?) selects these two ranges to update for %R2:R3
>
> [0B,56r:0)[368r,416r:5)...
> [0B,56r:0)[352r,...
2012 Aug 28
2
[LLVMdev] Assert in LiveInterval update
Andy,
I've described that issue (see below) when you were out of town... I think
I am getting more context on it. Please take a look...
So, in short, when the new MI scheduler performs move of an instruction, it
does something like this:
// Move the instruction to its new location in the instruction stream.
MachineInstr *MI = SU->getInstr();
if (IsTopNode) {