search for: reg1055

...is is apparently not always the case. For example: Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35) 308 %reg1051 = MOV64rr %reg1227<kill> 312 %reg1052 = MOV64rr %reg1228<kill> 316 %reg1053 = MOV64rr %reg1229<kill> 320 %reg1054 = MOV64rr %reg1230<kill> 324 %reg1055<dead> = LEA64r %reg1047, 1, %reg1053, 0 328 %reg1135 = MOVSX64rr32 %reg1025 332 %reg1136 = MOV64rr %reg1135<kill> 336 %reg1136 = ADD64ri32 %reg1136, -4, %EFLAGS<imp-def,dead> 340 TEST64rr %reg1136<kill>, %reg1136, %EFLAGS<imp-def> 344 JNS mbb<file solve.f, line 23,...

...se. For example: > > Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35) > 308 %reg1051 = MOV64rr %reg1227<kill> > 312 %reg1052 = MOV64rr %reg1228<kill> > 316 %reg1053 = MOV64rr %reg1229<kill> > 320 %reg1054 = MOV64rr %reg1230<kill> > 324 %reg1055<dead> = LEA64r %reg1047, 1, %reg1053, 0 > 328 %reg1135 = MOVSX64rr32 %reg1025 > 332 %reg1136 = MOV64rr %reg1135<kill> > 336 %reg1136 = ADD64ri32 %reg1136, -4, %EFLAGS<imp-def,dead> > 340 TEST64rr %reg1136<kill>, %reg1136, %EFLAGS<imp-def> > 344 JNS mbb&l...

...ase. For example: > > Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35) > 308 %reg1051 = MOV64rr %reg1227<kill> > 312 %reg1052 = MOV64rr %reg1228<kill> > 316 %reg1053 = MOV64rr %reg1229<kill> > 320 %reg1054 = MOV64rr %reg1230<kill> > 324 %reg1055<dead> = LEA64r %reg1047, 1, %reg1053, 0 > 328 %reg1135 = MOVSX64rr32 %reg1025 > 332 %reg1136 = MOV64rr %reg1135<kill> > 336 %reg1136 = ADD64ri32 %reg1136, -4, %EFLAGS<imp-def,dead> > 340 TEST64rr %reg1136<kill>, %reg1136, %EFLAGS<imp-def> > 344 JNS mbb&l...

On Thursday 17 January 2008 13:03, Evan Cheng wrote: > > So why does the live range extend throughout the entire basic block? > > > > %reg1055 doesn't appear anywhere else in the program so it shouldn't > > be > > live-in to the block. > > It could be a bug. Can you get me a test case? I'll see if I can whittle it down. It's a pretty huge function. If it's a coalescing bug it's probably in my c...

...9d60: i32,ch = LW 0x88c9540, 0x88ca9a8, 0x88c9dd8 SU(3): 0x88ca940: ch = TokenFactor 0x88ca7d8:1, 0x88c9d60:1 SU(2): 0x88ca8d8: i32 = ADDu 0x88ca7d8, 0x88c9d60 SU(7): 0x88c9d08: ch = SW 0x88ca8d8, 0x88c9540, 0x88ca6a8, 0x88ca940 Selected machine code: bb32: 0x88c8280, LLVM BB @0x88becf8, ID#10: %reg1055 = LUi <ga:flags.2176> %reg1056 = LW 0, <fi#7> %reg1057 = ADDiu %reg1055, <ga:flags.2176> %reg1058 = ADDiu %ZERO, 0 %reg1059 = ADDu %reg1057, %reg1056 SB %reg1058, 0, %reg1059 %reg1060 = LW 0, <fi#7> %reg1061 = LW 0, <fi#6> %reg1062 = ADDu %reg1060, %reg1061 SW...

...- %ar7, 8 %reg1054 = move %gr7 return shortcirc_done.1 (0x8065d90, LLVM BB @0x8060320): %reg1060 = phi %reg1032, mbb<shortcirc_next.0.selectcont.selectcont,0x8065c10> %reg1064 = phi %reg1035, mbb<shortcirc_next.0.selectcont.selectcont,0x8065c10> %reg1056 = move <ga:.str_1> %reg1055 = move %reg1056 %ar7 = + %ar7, 8 %reg1057 = - %ar7, 1 store %reg1057, %reg1055 %reg1058 = - %ar7, 2 store %reg1058, %reg1029 %reg1059 = - %ar7, 3 store %reg1059, %reg1060 %reg1061 = - %ar7, 4 %reg1062 = move 0 store %reg1061, %reg1062 %reg1063 = - %ar7, 5 store %reg1063, %reg1064 %reg1...

...you won't get the same output with upstream llvm -debug). ##### There's a sequence of instructions that looks like this before linear scan: ##### 2800 %reg1591<def> = SUB64rr %reg1591, %reg1589, %EFLAGS<imp-def,dead> ; srcLine 0 2808 %reg1591<def> = IMUL64rr %reg1591, %reg1055, %EFLAGS<imp-def,dead> ; srcLine 0 2816 %reg1591<def> = ADD64rr %reg1591, %reg1579, %EFLAGS<imp-def,dead> ; srcLine 0 2820 %reg1198<def> = LEA64r %reg1591, 1, %reg1574, 0 ; srcLine 0 ##### %reg1591 gets spilled by linear scan with all of the uses in the sequence above...