search for: vreg48

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 vreg48 are joined. It's right. But joining the following copy  912B%vreg32:sel_x<def,read-undef> = COPY %vreg48:sel_x; R600_Reg128:%vreg32,%vreg48 updates it to  928B%vreg34<def> = COPY %vreg32:sel_y; R600_Reg32:%vreg34 R600_Reg128:%vreg32 which is wrong....

> > PHIElim and TwoAddress passes leave SSA form. > May be a missed something in your code but %vreg48 seems to be there > after PHI elimination. PHIElim tags those kind of registers as being > PHIJoin regs, updating LiveVariables pass, so the regcoalescer is aware > of them (some SSA info is still alive but the reg coalescer will > invalidate that information after joining intervals...

...; 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 vreg48 are joined. It's right. > > But joining the following copy > > 912B%vreg32:sel_x<def,read-undef> = COPY %vreg48:sel_x; R600_Reg128:%vreg32,%vreg48 > > updates it to > 928B%vreg34<def> = COPY %vreg32:sel_y; R600_Reg32:%vreg3...

Thank for your help. You're right, merging vreg32 and vreg48 is perfectly fine, sorry I missed that. I "brute force" debuged by adding MachineFunction dump after each join, I think I found the issue : it's when vreg32 and vreg10 are merged. vreg10 only appears in BB#3, and the join only occurs in BB#3 apparently even if vreg32 lives in the 4 ma...

Vincent, File a bug report so you can get a fix for it. Ivan On 25/10/2012 23:01, Vincent Lejeune wrote: > Thank for your help. You're right, merging vreg32 and vreg48 is perfectly fine, sorry I missed that. > I "brute force" debuged by adding MachineFunction dump after each join, I think I found the issue : it's when vreg32 and vreg10 are merged. > vreg10 only appears in BB#3, and the join only occurs in BB#3 apparently even if vreg32 lives i...

...ent, On 24/10/2012 23:26, Vincent Lejeune wrote: > Hi, > > I don't know if my llvm ir code is faulty, or if I spot a bug in the RegisterCoalescing Pass, so I'm posting my issue on the ML. Shader and print-before-all dump are given below. > > The interessing part is the vreg6/vreg48 reduction : before RegCoalescing, the machine code is : > > // BEFORE LOOP > ... Some COPYs.... > 400B%vreg47<def> = COPY %vreg2<kill>; R600_Reg32:%vreg47,%vreg2 > 416B%vreg48<def> = COPY %vreg3<kill>; R600_Reg128:%vreg48,%vreg3 > 432B%vreg49<def> = C...

Hi, I don't know if my llvm ir code is faulty, or if I spot a bug in the RegisterCoalescing Pass, so I'm posting my issue on the ML. Shader and print-before-all dump are given below. The interessing part is the vreg6/vreg48 reduction : before RegCoalescing, the machine code is : // BEFORE LOOP ... Some COPYs.... 400B%vreg47<def> = COPY %vreg2<kill>; R600_Reg32:%vreg47,%vreg2 416B%vreg48<def> = COPY %vreg3<kill>; R600_Reg128:%vreg48,%vreg3 432B%vreg49<def> = COPY %vreg13<kill>; R600...

...so the CMP that sets the FLAGS reg in the second select was MCSE’ed to the earlier CMP in the first select, so here we see the second Select without a CMP: BB#10: derived from LLVM BB %for.body.5 Predecessors according to CFG: BB#3 BB#9 %vreg49<def> = PHI %vreg47, <BB#9>, %vreg48, <BB#3>; DataRegs:%vreg49,%vreg47,%vreg48 //// <=== this SLLI clobbers FLAGS <============ %vreg46<def> = SLLI %vreg5, 1, %FLAGS<imp-def,dead>; DataRegs:%vreg46,%vreg5 BCC 2, <BB#12>, %FLAGS<imp-use> Successors accord...

...FLAGS reg in the second select was MCSE’ed to the > earlier CMP in the first select, so here we see the second Select without a CMP: > > BB#10: derived from LLVM BB %for.body.5 > Predecessors according to CFG: BB#3 BB#9 > %vreg49<def> = PHI %vreg47, <BB#9>, %vreg48, <BB#3>; DataRegs:%vreg49,%vreg47,%vreg48 > > //// <=== this SLLI clobbers FLAGS <============ > %vreg46<def> = SLLI %vreg5, 1, %FLAGS<imp-def,dead>; DataRegs:%vreg46,%vreg5 > BCC 2, <BB#12>, %FLAGS<imp-use> &...

...cond select was MCSE’ed to the >> earlier CMP in the first select, so here we see the second Select without a CMP: >> >> BB#10: derived from LLVM BB %for.body.5 >> Predecessors according to CFG: BB#3 BB#9 >> %vreg49<def> = PHI %vreg47, <BB#9>, %vreg48, <BB#3>; DataRegs:%vreg49,%vreg47,%vreg48 >> >> //// <=== this SLLI clobbers FLAGS <============ >> %vreg46<def> = SLLI %vreg5, 1, %FLAGS<imp-def,dead>; DataRegs:%vreg46,%vreg5 >> BCC 2, <BB#12>, %FLAGS&...

...gt;>> earlier CMP in the first select, so here we see the second Select >>> without a CMP: >>> >>> BB#10: derived from LLVM BB %for.body.5 >>> Predecessors according to CFG: BB#3 BB#9 >>> %vreg49<def> = PHI %vreg47, <BB#9>, %vreg48, <BB#3>; >>> DataRegs:%vreg49,%vreg47,%vreg48 >>> >>> //// <=== this SLLI clobbers FLAGS <============ >>> %vreg46<def> = SLLI %vreg5, 1, %FLAGS<imp-def,dead>; >>> DataRegs:%vreg46,%vreg5 >>&...

...’ed to the >>> earlier CMP in the first select, so here we see the second Select without a CMP: >>> >>> BB#10: derived from LLVM BB %for.body.5 >>> Predecessors according to CFG: BB#3 BB#9 >>> %vreg49<def> = PHI %vreg47, <BB#9>, %vreg48, <BB#3>; DataRegs:%vreg49,%vreg47,%vreg48 >>> >>> //// <=== this SLLI clobbers FLAGS <============ >>> %vreg46<def> = SLLI %vreg5, 1, %FLAGS<imp-def,dead>; DataRegs:%vreg46,%vreg5 >>> BCC 2, <BB...

> On Jul 21, 2017, at 10:55 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > 2017-07-21 22:44 GMT-07:00 Peter Lawrence <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>>: > Mehdi, > Hal’s transformation only kicks in in the *presence* of UB > > No, sorry I entirely disagree with this assertion: I believe we