search for: 880b

...; = COPY %vreg28<kill>; R600_Reg128:%vreg3 R600_Reg32:%vreg28 register: %vreg3 replace range with [304r,320r:1) RESULT: [304r,320r:1)[320r,416r:0)  0 at 320r 1 at 304r 336B%vreg1<def> = COPY %vreg26<kill>; R600_Reg128:%vreg1,%vreg26 register: %vreg1 +[336r,448B:0) +[448B,592B:0) +[880B,1168B:0) +[592B,832r:0) 352B%vreg1:sel_w<def> = COPY %vreg17<kill>; R600_Reg128:%vreg1 R600_TReg32:%vreg17 register: %vreg1 replace range with [336r,352r:1) RESULT: [336r,352r:1)[352r,832r:0)[880B,1168B:0)  0 at 352r 1 at 336r 368B%vreg13<def> = MOV 1, 0, 0, 0, %ALU_LITERAL_X, 0,...

...;; R600_Reg128:%vreg3 > R600_Reg32:%vreg28 > register: %vreg3 replace range with [304r,320r:1) RESULT: > [304r,320r:1)[320r,416r:0)  0 at 320r 1 at 304r > 336B%vreg1<def> = COPY %vreg26<kill>; R600_Reg128:%vreg1,%vreg26 > register: %vreg1 +[336r,448B:0) +[448B,592B:0) +[880B,1168B:0) +[592B,832r:0) > 352B%vreg1:sel_w<def> = COPY %vreg17<kill>; R600_Reg128:%vreg1 > R600_TReg32:%vreg17 > register: %vreg1 replace range with [336r,352r:1) RESULT: > [336r,352r:1)[352r,832r:0)[880B,1168B:0)  0 at 352r 1 at 336r > 368B%vreg13<def> = MOV 1, 0...

...> = LGR %R4D<kill> // R2 = R4 could be optimized to -> %R2D<def> = LA %R2D<kill>, 4, %noreg // R2 = R2 + 4 The reason this wasn't coalesced, is because of overlapping during coalescing: 864B %vreg11<def> = LA %vreg2, 4, %noreg 880B %vreg16<def> = LLCMux %vreg2, 4, %noreg 928B %vreg2<def> = COPY %vreg11 It seems that if this had been rescheduled to 880B %vreg16<def> = LLCMux %vreg2, 4, %noreg 864B %vreg11<def> = LA %vreg2, 4, %noreg 928B %vreg2&l...

...l>, sel_x; R600_Reg128:%vreg32,%vreg33 R600_Reg32:%vreg31 > 848B%vreg34<def> = COPY %vreg6:sel_y; R600_Reg32:%vreg34 R600_Reg128:%vreg6 > 864B%vreg35<def,tied1> = INSERT_SUBREG %vreg32<tied0>, %vreg34<kill>, sel_y; R600_Reg128:%vreg35,%vreg32 R600_Reg32:%vreg34 > 880B%vreg36<def,tied1> = INSERT_SUBREG %vreg35<tied0>, %vreg5, sel_z; R600_Reg128:%vreg36,%vreg35 R600_Reg32:%vreg5 > 896B%vreg37<def> = COPY %vreg6:sel_w; R600_Reg32:%vreg37 R600_Reg128:%vreg6 > 912B%vreg10<def,tied1> = INSERT_SUBREG %vreg36<tied0>, %vreg37<kill&g...

...d see how it goes. I tried setting isUndef to trie when handling INSERT_SUBREG in TwoAddressInstructioPass.cpp, but then I run into stuff like this instead: 832B %vreg50:hi16<def,read-undef> = COPY %vreg0 848B ... 864B %vreg19<def,dead> = COPY %vreg50 880B %vreg19:lo16<def,read-undef> = COPY %vreg73 896B ... 912B mv_a32_r16_rmod1 %vreg19, %vreg20 ... *** Bad machine code: Multiple connected components in live interval *** - function: fixedconv - interval: %vreg19 [864r,864d:0)[880r,1024r:1) 0 at 864r 1...

...%vreg31<kill>, sel_x; R600_Reg128:%vreg32,%vreg33 R600_Reg32:%vreg31 848B%vreg34<def> = COPY %vreg6:sel_y; R600_Reg32:%vreg34 R600_Reg128:%vreg6 864B%vreg35<def,tied1> = INSERT_SUBREG %vreg32<tied0>, %vreg34<kill>, sel_y; R600_Reg128:%vreg35,%vreg32 R600_Reg32:%vreg34 880B%vreg36<def,tied1> = INSERT_SUBREG %vreg35<tied0>, %vreg5, sel_z; R600_Reg128:%vreg36,%vreg35 R600_Reg32:%vreg5 896B%vreg37<def> = COPY %vreg6:sel_w; R600_Reg32:%vreg37 R600_Reg128:%vreg6 912B%vreg10<def,tied1> = INSERT_SUBREG %vreg36<tied0>, %vreg37<kill>, sel_w;...

Hi, I have a problem regarding sub-register definitions and LiveIntervals on our target. When a subregister is defined, other parts of the register are always left untouched - they are neither read or def:ed. It however seems that Codegen treats subregister definitions as somehow clobbering the whole register. The SSA-code looks like this after isel: (Reg0 and Reg1 are 16bit registers. Reg2,

...symlinks, but they stood in a way, so I had to remove them. Also, the redhat-releae\* package could be -workstation, -server, -computernode, or -client. Any comments? Best, Mat?j -- https://matej.ceplovi.cz/blog/, Jabber: mcepl at ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 "Push to test." (click) "Release to detonate..." -- from a bugzilla quip list -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http:/...

...=thinSteps) ############################################################ -- ============================================================================== David Kaplan, Ph.D. Professor and Chair Department of Educational Psychology University of Wisconsin - Madison Educational Sciences, Room, 880B 1025 W. Johnson Street Madison, WI 53706 email: dkaplan at education.wisc.edu homepage: edpsych.education.wisc.edu/people/faculty-staff/david-kaplan Project page: bise.wceruw.org Phone: 608-262-0836

...8a 17ba 50d1 6354 ...F...TD...P.cT 0x03c0: 2709 2f38 34d7 8fdd 4ff4 bed5 bdda 8bc1 './84...O....... 0x03d0: dbbd 328f 107d 7a1b d4a8 d7cf 66f2 fee0 ..2..}z.....f... 0x03e0: 328b 0b6f 6606 bfe3 af0c 591f 6b69 269d 2..of.....Y.ki&. 0x03f0: 82ef 891a 8b85 cb38 b088 1eaf 880b 43be .......8......C. 0x0400: 53a5 5f7b 5fe4 790e 6a09 f27b df77 0117 S._{_.y.j..{.w.. 0x0410: 53c7 0041 72f0 b80e a3ab 7569 b8eb 7292 S..Ar.....ui..r. 0x0420: ba83 6122 e237 b55e 1f7a 0f37 3462 1f40 ..a".7.^.z.74b.@ 0x0430: 7629 fbfe b93c 9d19 aa81 257e 00ac 6631 v)......

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 machine blocks After joining, there

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