search for: vreg64

Hi, I'm having some trouble understanding if the live intervals calculated for one of my testcases are correct or not. I have the following instructions: 272L %vreg67:lo<def> = mv_any16 65535; R:%vreg67 288L %vreg64:hi<def> = mv_any16 16383; R:%vreg64 304L %vreg64:lo<def> = COPY %vreg67:lo; R:%vreg64,%vreg67 320L %vreg6<def> = COPY %vreg64<kill>; R:%vreg6,%vreg64 So, %vreg64, which has two (disjunct) sub registers, gets its two parts written at 288 and 304, and then the whole %vreg64...

...>, %vreg3, <BB#3> Successors according to CFG: BB#5 The observation I made here is that %vreg7 and %vreg4 are sort of nested PHI nodes, while there are no other users of the registers than the PHI nodes themselves. There is however a use of %vreg46, which later gets coalesced with %vreg64, which will include as well the two PHI nodes. This is the code with the two equivalence classes, when verifier aborts: 2272B BB#1: derived from LLVM BB %bb3 Predecessors according to CFG: BB#8 2304B %vreg64<def> = mov 0 2448B jmp <BB#5>...

...3> >> Successors according to CFG: BB#5 >> >> The observation I made here is that %vreg7 and %vreg4 are sort of nested PHI nodes, while there are no other users of the registers than the PHI nodes themselves. There is however a use of %vreg46, which later gets coalesced with %vreg64, which will include as well the two PHI nodes. >> >> This is the code with the two equivalence classes, when verifier aborts: >> >> 2272B BB#1: derived from LLVM BB %bb3 >> Predecessors according to CFG: BB#8 >> 2304B %vreg64<def> =...

...Successors according to CFG: BB#5 >>>> >>>> The observation I made here is that %vreg7 and %vreg4 are sort of nested PHI nodes, while there are no other users of the registers than the PHI nodes themselves. There is however a use of %vreg46, which later gets coalesced with %vreg64, which will include as well the two PHI nodes. >>>> >>>> This is the code with the two equivalence classes, when verifier aborts: >>>> >>>> 2272B BB#1: derived from LLVM BB %bb3 >>>> Predecessors according to CFG: BB#8 >&g...

...ding to CFG: BB#5 >>>>>> >>>>>> The observation I made here is that %vreg7 and %vreg4 are sort of nested PHI nodes, while there are no other users of the registers than the PHI nodes themselves. There is however a use of %vreg46, which later gets coalesced with %vreg64, which will include as well the two PHI nodes. >>>>>> >>>>>> This is the code with the two equivalence classes, when verifier aborts: >>>>>> >>>>>> 2272B BB#1: derived from LLVM BB %bb3 >>>>>> Pr...

...elow, it all depends in which iteration each instruction is scheduled and/or the order in which the instructions are scheduled. %vreg73<def> = PHI %vreg59, <BB#5>, %vreg62, <BB#6>; %vreg61<def> = INSN1 %vreg1, %vreg73; %vreg62<def> = INSN2 %vreg73, %vreg5; %vreg64<def> = INSN1 %vreg2, %vreg73; For some reason, the instruction defining vreg64 was scheduled after the instruction defining vreg62, which causes the copy to be generated. Then, the question is why did that happen? That can be hard to answer without seeing the debug output from the pipeli...

Hi - I replied to the original sender only by mistake. Sorry about that. When we started working on the pipeliner, and added it before the scheduler, we also were concerned that the scheduler or other passes would undo the work of the pipeliner. The initial thought was that we would add information (using metadata or some other way like you've suggested) to the basic block to tell the

Hi, I have some questions about the implementation of Software pipeline in MachinePipeliner.cpp. First, in hexagon backend, between MachinePipeliner and regalloc pass, there're some other passes like phi eliminate, two-address, register coalescing, which may change or insert intructions like 'copy' in MBB, and swp kernel loop may be destroyed by these passes. Why not put