Displaying 5 results from an estimated 5 matches for "reg1051".
Did you mean:
reg1031
2008 Jan 16
4
[LLVMdev] LiveInterval Questions
I had been assuming that give a LiveRange a, a.valno->def, if
valid, would be the same as a.start. But this 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&g...
2008 Jan 17
0
[LLVMdev] LiveInterval Questions
...08, at 11:49 AM, David Greene wrote:
> I had been assuming that give a LiveRange a, a.valno->def, if
> valid, would be the same as a.start. But this 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 %reg113...
2007 Jul 12
1
[LLVMdev] backend problem with LiveInterval::removeRange
...a0:1
SU(6): 0x88c9c28: ch = BEQ 0x88c9ba0, 0x88c8a08, 0x88ca710, 0x88ca778
Selected machine code:
bb20: 0x88c8140, LLVM BB @0x88bec48, ID#8:
%reg1047 = LUi <ga:flags.2176>
%reg1048 = LW 0, <fi#6>
%reg1049 = ADDiu %reg1047, <ga:flags.2176>
%reg1050 = ADDu %reg1049, %reg1048
%reg1051 = LBu 0, %reg1050
%reg1052 = ADDiu %ZERO, 0
BEQ %reg1051, %reg1052, mbb<cond_next46,0x88c8430>
Successors according to CFG: 0x88c8430 (#13) 0x88c8218 (#9)
Total amount of phi nodes to update: 0
Replacing.1 0x88c8d00: ch = TokenFactor 0x88c9540:1, 0x88c9540:1
With: 0x88c9540: i32,ch = l...
2008 Jan 17
0
[LLVMdev] LiveInterval Questions
...008, at 11:49 AM, David Greene wrote:
> I had been assuming that give a LiveRange a, a.valno->def, if
> valid, would be the same as a.start. But this 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 %reg113...
2004 Jun 22
3
[LLVMdev] Linearscan allocator bug?
...1041 = move %reg1042
%ar7 = + %ar7, 8
%reg1043 = - %ar7, 1
store %reg1043, %reg1041
%reg1044 = - %ar7, 2
store %reg1044, %reg1029
%reg1045 = - %ar7, 3
store %reg1045, %reg1046
%reg1047 = - %ar7, 4
%reg1048 = move 0
store %reg1047, %reg1048
%reg1049 = - %ar7, 5
store %reg1049, %reg1050
%reg1051 = - %ar7, 6
%reg1052 = move 0
store %reg1051, %reg1052
%reg1053 = - %ar7, 7
store %reg1053, %reg1039
call <ga:printf>
%ar7 = - %ar7, 8
%reg1054 = move %gr7
return
shortcirc_done.1 (0x8065d90, LLVM BB @0x8060320):
%reg1060 = phi %reg1032, mbb<shortcirc_next.0.selectcont.selectcont...