search for: ___but____

...s::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 update, my new ranges look like this: R2 = [0B,32r:0)[352r,416r:5)... R3 = [0B,48r:0)[368r,416r:5)...<<<<< Bogus range, 56r should have become 48r R4 = [0B,48r:0)[384r,416r:4)... R5 = [0B,48r:0)[400r,416r:4)... .... 0B BB#0: derived from LLVM BB %entry Live Ins: %R0 %...

...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 update, my new ranges look like this: > > R2 = [0B,32r:0)[352r,416r:5)... > R3 = [0B,48r:0)[368r,416r:5)...<<<<< Bogus range, 56r should have become > 48r > R4 = [0B,48r:0)[384r,416r:4)... > R5 = [0B,48r:0)[400r,416r:4)... > .... > 0B BB#0: deri...

...s::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 update, my new ranges look like this: R2 = [0B,32r:0)[352r,416r:5)... R3 = [0B,48r:0)[368r,416r:5)...<<<<< Bogus range, 56r should have become 48r R4 = [0B,48r:0)[384r,416r:4)... R5 = [0B,48r:0)[400r,416r:4)... .... 0B BB#0: derived from LLVM BB %entry Liv...

...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 update, my new ranges look like this: > > R2 = [0B,32r:0)[352r,416r:5)... > R3 = [0B,48r:0)[368r,416r:5)...<<<<< Bogus range, 56r should have > become 48r > R4 = [0B,48r:0)[384r,416r:4)... > R5 = [0B,48r:0)[400r,416r:4)... > .... > 0B BB#0: derived...

...s::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 update, my new ranges look like this: R2 = [0B,32r:0)[352r,416r:5)... R3 = [0B,48r:0)[368r,416r:5)...<<<<< Bogus range, 56r should have become 48r R4 = [0B,48r:0)[384r,416r:4)... R5 = [0B,48r:0)[400r,416r:4)... .... 0B BB#0: derived from LLVM BB %entry Liv...

...r 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 update, my new ranges look like this: >> >> R2 = [0B,32r:0)[352r,416r:5)... >> R3 = [0B,48r:0)[368r,416r:5)...<<<<< Bogus range, 56r should have >> become 48r >> R4 = [0B,48r:0)[384r,416r:4)... >> R5 = [0B,48r:0)[400r,416r:4)... >>...

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

...her 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 update, my new ranges look like this: > >> > >> R2 = [0B,32r:0)[352r,416r:5)... > >> R3 = [0B,48r:0)[368r,416r:5)...<<<<< Bogus range, 56r should have > >> become 48r > >> R4 = [0B,48r:0)[384r,416r:4)... > >> R5 = [0B,48...

...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 update, my new ranges look like this: > > R2 = [0B,32r:0)[352r,416r:5)... > R3 = [0B,48r:0)[368r,416r:5)...<<<<< Bogus range, 56r should have become > 48r > R4 = [0B,48r:0)[384r,416r:4)... > R5 = [0B,48r:0)[400r,416r:4)... > .... > 0B BB#0: deri...

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) {