search for: vreg42

...32:%vreg39 %vreg40<def> = COPY %vreg32:sel_y; R600_Reg32:%vreg40 R600_Reg128:%vreg32 %T2_Y<def> = COPY %vreg40<kill>; R600_Reg32:%vreg40 %vreg41<def> = COPY %vreg32:sel_z; R600_Reg32:%vreg41 R600_Reg128:%vreg32 %T2_Z<def> = COPY %vreg41<kill>; R600_Reg32:%vreg41 %vreg42<def> = COPY %vreg32:sel_w; R600_Reg32:%vreg42 R600_Reg128:%vreg32 %T2_W<def> = COPY %vreg42<kill>; R600_Reg32:%vreg42 %vreg43<def> = COPY %vreg1:sel_x; R600_Reg32:%vreg43 R600_Reg128:%vreg1 %T1_X<def> = COPY %vreg43<kill>; R600_Reg32:%vreg43 %vreg44<def> =...

Hi Vincent, On 25/10/2012 18:14, Vincent Lejeune wrote: > When examining the debug output of regalloc, it seems that joining 32bits reg also joins 128 parent reg. > > If I look at the : > %vreg34<def> = COPY %vreg6:sel_y; R600_Reg32:%vreg34 R600_Reg128:%vreg6 > > instructions ; it gets joined to : > 928B%vreg34<def> = COPY %vreg48:sel_y; > > when vreg6 and

...t;def> = COPY %vreg32:sel_y; R600_Reg32:%vreg40 R600_Reg128:%vreg32 > %T2_Y<def> = COPY %vreg40<kill>; R600_Reg32:%vreg40 > %vreg41<def> = COPY %vreg32:sel_z; R600_Reg32:%vreg41 R600_Reg128:%vreg32 > %T2_Z<def> = COPY %vreg41<kill>; R600_Reg32:%vreg41 > %vreg42<def> = COPY %vreg32:sel_w; R600_Reg32:%vreg42 R600_Reg128:%vreg32 > %T2_W<def> = COPY %vreg42<kill>; R600_Reg32:%vreg42 > %vreg43<def> = COPY %vreg1:sel_x; R600_Reg32:%vreg43 R600_Reg128:%vreg1 > %T1_X<def> = COPY %vreg43<kill>; R600_Reg32:%vreg43 > %...

...vreg40<def> = COPY %vreg6:sel_y; R600_Reg32:%vreg40 R600_Reg128:%vreg6 656B%T2_Y<def> = COPY %vreg40<kill>; R600_Reg32:%vreg40 672B%vreg41<def> = COPY %vreg6:sel_z; R600_Reg32:%vreg41 R600_Reg128:%vreg6 688B%T2_Z<def> = COPY %vreg41<kill>; R600_Reg32:%vreg41 704B%vreg42<def> = COPY %vreg6:sel_w<kill>; R600_Reg32:%vreg42 R600_Reg128:%vreg6 720B%T2_W<def> = COPY %vreg42<kill>; R600_Reg32:%vreg42 And after the pass : //Before Loop ...Some COPYs... 128B%vreg27:sel_x<def,read-undef> = COPY %C1_X; R600_Reg128:%vreg27 192B%vreg27:sel_y<...

...COPY %vreg6:sel_y; R600_Reg32:%vreg40 R600_Reg128:%vreg6 > 656B%T2_Y<def> = COPY %vreg40<kill>; R600_Reg32:%vreg40 > 672B%vreg41<def> = COPY %vreg6:sel_z; R600_Reg32:%vreg41 R600_Reg128:%vreg6 > 688B%T2_Z<def> = COPY %vreg41<kill>; R600_Reg32:%vreg41 > 704B%vreg42<def> = COPY %vreg6:sel_w<kill>; R600_Reg32:%vreg42 R600_Reg128:%vreg6 > 720B%T2_W<def> = COPY %vreg42<kill>; R600_Reg32:%vreg42 > > And after the pass : > > //Before Loop > ...Some COPYs... > 128B%vreg27:sel_x<def,read-undef> = COPY %C1_X; R600_Reg...

...128:%vreg6 register: %vreg40 +[640r,656r:0) 656B%T2_Y<def> = COPY %vreg40<kill>; R600_Reg32:%vreg40 672B%vreg41<def> = COPY %vreg6:sel_z; R600_Reg32:%vreg41 R600_Reg128:%vreg6 register: %vreg41 +[672r,688r:0) 688B%T2_Z<def> = COPY %vreg41<kill>; R600_Reg32:%vreg41 704B%vreg42<def> = COPY %vreg6:sel_w<kill>; R600_Reg32:%vreg42 R600_Reg128:%vreg6 register: %vreg42 +[704r,720r:0) 720B%T2_W<def> = COPY %vreg42<kill>; R600_Reg32:%vreg42 736B%vreg43<def> = COPY %vreg1:sel_x; R600_Reg32:%vreg43 R600_Reg128:%vreg1 register: %vreg43 +[736r,752r:0) 7...

...640r,656r:0) > 656B%T2_Y<def> = COPY %vreg40<kill>; R600_Reg32:%vreg40 > 672B%vreg41<def> = COPY %vreg6:sel_z; R600_Reg32:%vreg41 > R600_Reg128:%vreg6 > register: %vreg41 +[672r,688r:0) > 688B%T2_Z<def> = COPY %vreg41<kill>; R600_Reg32:%vreg41 > 704B%vreg42<def> = COPY %vreg6:sel_w<kill>; R600_Reg32:%vreg42 > R600_Reg128:%vreg6 > register: %vreg42 +[704r,720r:0) > 720B%T2_W<def> = COPY %vreg42<kill>; R600_Reg32:%vreg42 > 736B%vreg43<def> = COPY %vreg1:sel_x; R600_Reg32:%vreg43 > R600_Reg128:%vreg1 > re...

...to support virtregs - VirtRegs are assumed to have a definition, physregs can appear "out of thin air" in some situations like function parameters, or exception objects appearing in a register when going to a landingpad. - VirtRegs are assumed to be interchangeable, replaceing vreg5 with vreg42 shouldn't affect the program semanic (given they both have the same register class and we have no other defs/uses of vreg42), if you use virtregs for parameter passing this won't be true anymore - regmask clobbers only affect physregs (- You cannot reuse the existing regalloc infrastructure...

...ng to a landingpad. >> > > This is what Dan is trying to address with http://reviews.llvm.org/D14750. > The discussion on that change is essentially the same as the one going on > here. > > >> - VirtRegs are assumed to be interchangeable, replaceing vreg5 with >> vreg42 shouldn't affect the program semanic (given they both have the same >> register class and we have no other defs/uses of vreg42), if you use >> virtregs for parameter passing this won't be true anymore >> > > I believe this would be addressed for wasm with a mechanism...

...;> >> This is what Dan is trying to address with http://reviews.llvm.org/D14750. >> The discussion on that change is essentially the same as the one going on >> here. >> >> >>> - VirtRegs are assumed to be interchangeable, replaceing vreg5 with >>> vreg42 shouldn't affect the program semanic (given they both have the same >>> register class and we have no other defs/uses of vreg42), if you use >>> virtregs for parameter passing this won't be true anymore >>> >> >> I believe this would be addressed for w...

----- Original Message ----- > From: "Kevin B Smith" <kevin.b.smith at intel.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>, llvm-dev at lists.llvm.org > Sent: Thursday, December 10, 2015 2:32:36 PM > Subject: RE: [llvm-dev] Allowing virtual registers after register allocation >

...;>> This is what Dan is trying to address with http://reviews.llvm.org/D14750 <http://reviews.llvm.org/D14750>. The discussion on that change is essentially the same as the one going on here. >>> >>> - VirtRegs are assumed to be interchangeable, replaceing vreg5 with vreg42 shouldn't affect the program semanic (given they both have the same register class and we have no other defs/uses of vreg42), if you use virtregs for parameter passing this won't be true anymore >>> >>> I believe this would be addressed for wasm with a mechanism like that...