search for: handlemov

.... My current problem is that I had to implement this whole incremental liveness analysis in my late pass... (because LIS does not work that late)... which is something I do not want to carry forward for too long if I can avoid it. In short, I do need a version of "move instruction" (or handleMove) that would produce accurate global liveness after its use. If LIS.beginChanges(); // change // LIS.endChanges(); will work as fast and efficiently, no problem then, but I have this feeling that incremental liveness update (when possible) will be easier and cheaper than full scan. You have a...

...moving these COPY at later positions 104B and 112B. The new code sequence leaves two FMUL_A_oo without COPY. So this requires 2 registers from FPUaROUTMULRegisterClass (which only includes FA_ROUTMUL). So spill out need to be inserted where I tried to avoid it by inserting the COPY. :-/ This 'handleMove' is generated by LiveIntervalAnalysis, but I don't understand why it is generated and how to avoid this counterproductive optimization. TIA, Dominique Torette. # *** IR Dump After MachineFunction Printer ***: # Machine code for function addproddivConst: Post SSA Function Live Ins:...

...; What is the current thinking? Will we ever be able to move an instruction > between BBs and have liveness updated properly? If so, what interface will > we need for that? Based on your answer, original question might become a bit > more easy to answer. Good question. We currently have handleMove() which will update liveness after moving a single instruction within a basic block. I could see it being extended to handle globally moved instructions as well. I am wary of an API that automatically updates liveness because it can be expensive to maintain valid liveness along a number of interm...

Jakob, Seems like an easy solution for this case... But let me ask you a more general question. The reason I kept on hanging on to the MBB->splice was (probably outdated) assumption that it will one day properly update liveness for instructions it moves... That is a serious matter for what I am trying to do (global code motion in presence of bundles). What is the current thinking? Will

...se>, %R0<imp-use,undef> Hexagon MI scheduler is working with BB1 and picks this load: %vreg10<def> = LDriw %vreg9<kill>, 0; mem:LD4[%stack.0.in] IntRegs:%vreg10,%vreg9 To be scheduled first (!). Right there after 7 clang 0x000000000226aece llvm::LiveIntervals::handleMove(llvm::MachineInstr*) + 378 8 clang 0x0000000001c2574f llvm::VLIWMachineScheduler::listScheduleTopDown() + 595 9 clang 0x0000000001c24cd5 llvm::VLIWMachineScheduler::schedule() + 505 It does not seem to happen on the trunk. My question is - Does anyone recognizes the issue,...

...MEditor::moveAllInternalFrom (this=0x7fffffff8010, OldIdx=..., Internal=...) at lib/CodeGen/LiveIntervalAnalysis.cpp:1226 #7 in llvm::LiveIntervals::HMEditor::moveAllRangesFrom (this=0x7fffffff8010, MI=0x462ab80, OldIdx=...) at lib/CodeGen/LiveIntervalAnalysis.cpp:938 #8 in llvm::LiveIntervals::handleMove (this=0x448b6f0, MI=0x462ab80) at lib/CodeGen/LiveIntervalAnalysis.cpp:1388 #9 in llvm::VLIWMachineScheduler::moveInstruction (this=0x46b0f50, MI=0x462ab80, InsertPos=...) at lib/Target/Hexagon/HexagonMachineScheduler.cpp:120 #10 in llvm::VLIWMachineScheduler::schedule (this=0x46b0f50) at lib/...

...on MI scheduler is working with BB1 and picks this load: > > %vreg10<def> = LDriw %vreg9<kill>, 0; mem:LD4[%stack.0.in] > IntRegs:%vreg10,%vreg9 > > To be scheduled first (!). Right there after > > 7 clang 0x000000000226aece > llvm::LiveIntervals::handleMove(llvm::MachineInstr*) + 378 > 8 clang 0x0000000001c2574f > llvm::VLIWMachineScheduler::listScheduleTopDown() + 595 > 9 clang 0x0000000001c24cd5 llvm::VLIWMachineScheduler::schedule() > + 505 > > It does not seem to happen on the trunk. > > My question...

...triggers SlotIndex 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____ a...

Hi, I wonder when the preRASched pass is planned to be available? I wonder how one would best try to implement a pass in between RegCoalescer and RA. After RegCoalescer, the LiveVariables information seems broken (there are no Kills anywhere), and LiveVariables can't be rerun after SSA form is left. So, how could one rebuild LiveIntevals? For register allocation purposes - what would be the

...mbered 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,56...

On Aug 13, 2012, at 8:34 AM, Sergei Larin <slarin at codeaurora.org> wrote: > Andy, > > Yes, this is what Arnold has suggested also, and from this point it looks > like it should work, but it will require parsing the bundle every time we > care to know whether this is a real use or a conditional def. This might > become awkward... but I guess I should provide a better

On Jun 3, 2013, at 9:42 AM, Steve Montgomery <stephen.montgomery3 at btinternet.com> wrote: > Hi Jakob, > > thanks for the advice. I'll do as you suggest and make sure that CCR is never live. > > I can use pseudo-instructions to bundle cmp+jump but it's not ideal because I might also have to bundle cmp+jump+jump+... into a pseudo. Also, there are several flavours of

...gt; (this=0x7fffffff8010, OldIdx=..., Internal=...) at > lib/CodeGen/LiveIntervalAnalysis.cpp:1226 > #7 in llvm::LiveIntervals::HMEditor::moveAllRangesFrom > (this=0x7fffffff8010, MI=0x462ab80, OldIdx=...) at > lib/CodeGen/LiveIntervalAnalysis.cpp:938 > #8 in llvm::LiveIntervals::handleMove (this=0x448b6f0, MI=0x462ab80) > at > lib/CodeGen/LiveIntervalAnalysis.cpp:1388 > #9 in llvm::VLIWMachineScheduler::moveInstruction (this=0x46b0f50, > MI=0x462ab80, InsertPos=...) at > lib/Target/Hexagon/HexagonMachineScheduler.cpp:120 > #10 in llvm::VLIWMachineScheduler::sch...

...triggers SlotIndex 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____ a...

On Jun 11, 2012, at 12:07 PM, Hal Finkel <hfinkel at anl.gov> wrote: > Looking at VLIWPacketizerList::PacketizeMIs, it seems like the > instructions are first scheduled (via some external scheme?), and then > packetized 'in order'. Is that correct? Anshu? > In the PowerPC grouping scheme, resources are assigned on a group > basis (by the instruction dispatching

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

...triggers SlotIndex 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____ a...

Hi Jakob, thanks for the advice. I'll do as you suggest and make sure that CCR is never live. I can use pseudo-instructions to bundle cmp+jump but it's not ideal because I might also have to bundle cmp+jump+jump+... into a pseudo. Also, there are several flavours of cmp instruction so I might need a lot of pseudos. That's what led me to wonder whether MachineInstrBundles might be a

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

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