search for: reg1045

...d to replace INSERT_SUBREG, EXTRACT_SUBREG, and virtual register copies after instruction selection. Selection DAG still needs {INSERT,EXTRACT}_SUBREG, but they would not appear as MachineInstrs any longer. > > The COPY instruction handles subreg operations with less redundancy: > > %reg1045<def> = EXTRACT_SUBREG %reg1044<kill>, 4 > %reg1045<def> = COPY %reg1044:sub_32bit<kill> > > %reg1045<def> = INSERT_SUBREG %reg1045, %reg1044<kill>, 4 > %reg1045:sub_32bit<def> = COPY %reg1044<kill> > > %reg1050:ssub_0<def&gt...

...ion. It would be used to replace INSERT_SUBREG, EXTRACT_SUBREG, and virtual register copies after instruction selection. Selection DAG still needs {INSERT,EXTRACT}_SUBREG, but they would not appear as MachineInstrs any longer. The COPY instruction handles subreg operations with less redundancy: %reg1045<def> = EXTRACT_SUBREG %reg1044<kill>, 4 %reg1045<def> = COPY %reg1044:sub_32bit<kill> %reg1045<def> = INSERT_SUBREG %reg1045, %reg1044<kill>, 4 %reg1045:sub_32bit<def> = COPY %reg1044<kill> %reg1050:ssub_0<def> = EXTRACT_SUBREG %reg1060:ds...

...t; > LiveInterval &RegInt = getInterval(reg); > RegInt.weight += > (mop.isUse() + mop.isDef()) * pow(10.0F, (int)loopDepth); > After joining intervals some moves are unecessary. If for example this instruction was in the code: mov %reg1024, %reg1045 and intervals for reg1024 and reg1045 were joined, only one register needs to be present in the pre register-allocation machine code. So all references to reg1024 and reg1045 are replaced with a reference to their representative register (found using a union find algorithm). Note that the represen...

I don't understand the following code snippet in LiveIntervalAnalysis.cpp. Why changing the type of the opreand from a virtual register to a machine register? The register number (reg) is still a virtual register index (>1024). bool LiveIntervals::runOnMachineFunction(MachineFunction &fn) { // perform a final pass over the instructions and compute spill // weights, coalesce

...i32 = SLT 0x88c8c88, 0x88c96a8 SU(3): 0x88c99a8: ch = BNE 0x88c8900, 0x88c9640, 0x88c9540, 0x88c8c88:1 Selected machine code: bb14: 0x88c8020, LLVM BB @0x88beb98, ID#6: Predecessors according to CFG: 0x88c7ed8 (#4) 0x88c7f90 (#5) %reg1043 = ADDiu %ZERO, 8193 %reg1044 = LW 0, <fi#6> %reg1045 = SLT %reg1044, %reg1043 BNE %reg1045, %ZERO, mbb<bb9,0x88c7f90> Successors according to CFG: 0x88c7f90 (#5) 0x88c80b0 (#7) Total amount of phi nodes to update: 0 Lowered selection DAG: SelectionDAG has 7 nodes: 0x88c8bf0: ch = EntryToken 0x88ca270: i32 = Constant <2>...

Hi Hisham, Most likely the basic blocks are the headers of two different loops. Try running viewCFG() on the function in question to see if this is the case. Tom ----- Original Message ----- From: "Hisham Chowdhury" <hisham_chow at yahoo.com> To: llvmdev at cs.uiuc.edu Sent: Wednesday, June 16, 2010 7:22:00 PM GMT -05:00 US/Canada Eastern Subject: [LLVMdev] Loopinfo Analysis

Hello, I have a question regrading the analysis pass that generates loop info from an .ll code. My previous understanding was there will be just one loop header(in the loop info) for a particular loop. But, when i use isLoopHeader() member function from the loop info class I get 'true' return value for two different basic blocks. Note both basic blocks are loop conditional block(break

...bb<shortcirc_next.1.selecttrue,0x8065cd0>, %reg1077, mbb<shortcirc_next.1,0x8065c70> %reg1039 = move %reg1040 %reg1042 = move <ga:.str_1> %reg1041 = 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 =...