search for: reg1033

I have two questions regarding MachineMemOperands and dependence information. Q1) I noticed that MachineMemOperands are lost when two LDRs are combined and a LDRD is generated in ARMPreAllocLoadStoreOpt:::RescheduleOps. (before optimization) %reg1033<def> = LDR %reg1030, %reg0, 4100, pred:14, pred:%reg0; mem:LD4[%uglygep10] %reg1054<def> = LDR %reg1030, %reg0, 4104, pred:14, pred:%reg0; mem:LD4[%uglygep2021] (after optimization) %reg1054<def>, %reg1033<def> = LDRD %reg1030, %reg0, 264, pred:14, pred:%reg0 Are there any...

..., Akira Hatanaka wrote: > I have two questions regarding MachineMemOperands and dependence information. > > Q1) I noticed that MachineMemOperands are lost when two LDRs are combined and a LDRD is generated in ARMPreAllocLoadStoreOpt:::RescheduleOps. > > (before optimization) > %reg1033<def> = LDR %reg1030, %reg0, 4100, pred:14, pred:%reg0; mem:LD4[%uglygep10] > %reg1054<def> = LDR %reg1030, %reg0, 4104, pred:14, pred:%reg0; mem:LD4[%uglygep2021] > > (after optimization) > %reg1054<def>, %reg1033<def> = LDRD %reg1030, %reg0, 264, pred:14, pred:...

...ave two questions regarding MachineMemOperands and dependence > information. > > > > Q1) I noticed that MachineMemOperands are lost when two LDRs are combined > and a LDRD is generated in ARMPreAllocLoadStoreOpt:::RescheduleOps. > > > > (before optimization) > > %reg1033<def> = LDR %reg1030, %reg0, 4100, pred:14, pred:%reg0; > mem:LD4[%uglygep10] > > %reg1054<def> = LDR %reg1030, %reg0, 4104, pred:14, pred:%reg0; > mem:LD4[%uglygep2021] > > > > (after optimization) > > %reg1054<def>, %reg1033<def> = LDRD %reg103...

...str_2> %reg1029 = LBZ 0, %reg1026 ADJCALLSTACKDOWN 56 %reg1030 = IMPLICIT_DEF_GPR %reg1031 = LA %reg1027, <ga:.str_1> %r3 = OR4 %reg1031, %reg1031 BL <ga:printf>, %r3 %reg1032 = OR4 %r3, %r3 <------------------- %reg1033 = EXTSB %reg1029 %reg1034 = LA %reg1028, <ga:.str_2> ADJCALLSTACKUP 56 ADJCALLSTACKDOWN 56 %r3 = OR4 %reg1034, %reg1034 %r4 = OR4 %reg1033, %reg1033 BL <ga:printf>, %r3, %r4 %reg1035 = OR4 %r3, %r3 ADJCALLSTACKUP 56...

...reg was not killed in defining block!"); in LiveIntervals::handlePhysicalRegisterDef(). The dump() of the MBB from the debugger looks like the following: entry.ifcont267_crit_edge: 0x12bc368, LLVM BB @0x12bb900, ID#2: Predecessors according to CFG: 0x12bc290 (#0) 0x12bca70 (#1) %reg1033<def> = addC %reg1025<kill>, 0, %CCFLAGS<imp-def,dead> %reg1032<def> = addC %reg1024<kill>, 0, %CCFLAGS<imp-def,dead> %reg1095<def> = addC %reg1028, 0, %CCFLAGS<imp-def> %reg1096<def> = addC %reg1029<kill>, 0, %CCFLA...

...g1073<def> = SHUFPDrri %reg1071, %reg1072, 0 ; srcLine 10 Actrually, it's worse than this. I wanted to check to make sure something else wasn't causing the problem but it appears to come from isel. The full output for the DAG looks like this: %reg1059<def> = MOVSX64rm32 %reg1033, 1, %reg0, 4, Mem:LD(4,4) [tmp163 + 0] ; srcLine 10 %reg1060<def> = MOVSDrm %reg1026, 8, %reg1059, 4294967288, Mem:LD(8,8) [r45154 + 0] ; srcLine 10 %reg1061<def> = MOVSX64rm32 %reg1033, 1, %reg0, 0, Mem:LD(4,4) [iv.161162 + 0] ; srcLine 10 %reg1062<def> = MOVSDrm %reg102...

...k!"); > > in LiveIntervals::handlePhysicalRegisterDef(). > > The dump() of the MBB from the debugger looks like the following: > > entry.ifcont267_crit_edge: 0x12bc368, LLVM BB @0x12bb900, ID#2: > Predecessors according to CFG: 0x12bc290 (#0) 0x12bca70 (#1) > %reg1033<def> = addC %reg1025<kill>, 0, %CCFLAGS<imp-def,dead> > %reg1032<def> = addC %reg1024<kill>, 0, %CCFLAGS<imp-def,dead> > %reg1095<def> = addC %reg1028, 0, %CCFLAGS<imp-def> > %reg1096<def> = addC %reg1029<kill&gt...

On Thu, 29 Jun 2006, Fernando Magno Quintao Pereira wrote: > I am working in a register allocator for LLVM, and I realized that, > after I perform register allocation, there is many move instructions that > are dead code, and can safely be removed. It is easy for the RA algorithm > to remove these instructions. It seems to me that the only instructions > with dead definitions

Dear guys, I am working in a register allocator for LLVM, and I realized that, after I perform register allocation, there is many move instructions that are dead code, and can safely be removed. It is easy for the RA algorithm to remove these instructions. It seems to me that the only instructions with dead definitions that I should not remove are the calls. Is it true? I would like to know

...reg1072, 0 ; srcLine 10 > > Actrually, it's worse than this. I wanted to check to make sure > something > else wasn't causing the problem but it appears to come from isel. > The full > output for the DAG looks like this: > > %reg1059<def> = MOVSX64rm32 %reg1033, 1, %reg0, 4, Mem:LD(4,4) > [tmp163 + > 0] ; srcLine 10 > %reg1060<def> = MOVSDrm %reg1026, 8, %reg1059, 4294967288, > Mem:LD(8,8) > [r45154 + 0] ; srcLine 10 > %reg1061<def> = MOVSX64rm32 %reg1033, 1, %reg0, 0, Mem:LD(4,4) [iv. > 161162 + > 0] ; srcLin...

...nything, I move the value into general purpose register, to "and" and then move it into address register. Unfortunately, the register allocator crashes. Here's machine code: %reg1030 = - %reg1027, 1 %reg1031 = move %reg1030 %reg1032 = + %reg1031, -2 %reg1033 = move %reg1032 %ar1 = load64 %gr1<def>, %reg1033 and here's assertion: llc: LiveIntervals.cpp:507: void llvm::LiveIntervals::joinIntervals(): Assertion `rcA == rcB && "registers must be of the same class"' failed. (gdb) up 4 ..... (gdb) p *intA $1 = (llvm...

On Thursday 02 October 2008 11:37, David Greene wrote: > I'll try ot write a small example and send it in a bit. Ok, here's what I'm trying to do: let AddedComplexity = 40 in { def : Pat<(v2f64 (vector_shuffle (v2f64 (scalar_to_vector (loadf64 addr: $src1))), (v2f64 (scalar_to_vector (loadf64 addr: $src2))),

...e the defs. Otherwise I might try to re-run LiveVariables after PNE, or some similiar approach combining these two passes - unless you tell me they don't get marked dead because of an implementation flaw in my backend (or something completely else : ) Thanks again, Christian >> %reg1033<def> = addC %reg1025<kill>, 0, %CCFLAGS<imp-def,dead> >> %reg1032<def> = addC %reg1024<kill>, 0, %CCFLAGS<imp-def,dead> >> %reg1095<def> = addC %reg1028, 0, %CCFLAGS<imp-def> >> %reg1096<def> = addC %reg102...

I'm debugging some X86 patterns and I want to understand the debug dumps from isel better. Here's some example output: 0x391bc40: i64,ch = load 0x3922c50, 0x391b8d0, 0x38dc530 <0x39053e0:0> <sext i32> alignment=4 srcLineNum= 10 0x3922c50: <multiple use> 0x391bc40: <multiple use> 0x3856ab0: <multiple use> 0x3914520: i64 =

...8968, 0x88c8cf0:1 SU(3): 0x88c9150: ch = SW 0x88c8d88, 0x88c8b58, 0x88c8a68, 0x88ca1e8 SU(2): 0x88c8af0: ch = J 0x88c8a00, 0x88c9150 Selected machine code: cond_next: 0x88c7e48, LLVM BB @0x88be1b8, ID#3: Predecessors according to CFG: 0x88c79a8 (#1) 0x88c7db8 (#2) %reg1032 = ADDiu %ZERO, 0 %reg1033 = LW 0, <fi#3> SW %reg1033, 0, <fi#5> SW %reg1032, 0, <fi#8> J mbb<bb55,0x88c8550> Successors according to CFG: 0x88c8550 (#15) Total amount of phi nodes to update: 0 Lowered selection DAG: SelectionDAG has 10 nodes: 0x88c9060: i32 = undef 0x88ca1e8: ch = E...

...move 1 setcc %reg1026, %reg1031 if v< goto %disp(label shortcirc_next.0.selecttrue) %reg1073 = move 0 goto %disp(label shortcirc_next.0.selectcont) shortcirc_next.0.selecttrue (0x8065af0, LLVM BB @0x8063bb0): %reg1072 = move 1 shortcirc_next.0.selectcont (0x8065b50, LLVM BB @0x8063b08): %reg1033 = phi %reg1072, mbb<shortcirc_next.0.selecttrue,0x8065af0>, %reg1073, mbb<shortcirc_next.0,0x8065a90> %reg1032 = move %reg1033 %reg1034 = move 1 setcc %reg1025, %reg1034 if v< goto %disp(label shortcirc_next.0.selectcont.selecttrue) %reg1075 = move 0 goto %disp(label shortcirc_...

...istencies): BB2: preheader, BB3: header & latch, BB4: exit (before transformation) BB#2: derived from LLVM BB %entry.bb_crit_edge Predecessors according to CFG: BB#0 %reg1025<def> = MOVr %reg1034<kill>, pred:14, pred:%reg0, opt:%reg0 %reg1024<def> = MOVr %reg1033<kill>, pred:14, pred:%reg0, opt:%reg0 %reg1036<def> = MOVi 0, pred:14, pred:%reg0, opt:%reg0 %reg1038<def> = MOVr %reg1024<kill>, pred:14, pred:%reg0, opt:%reg0 %reg1039<def> = MOVr %reg1025<kill>, pred:14, pred:%reg0, opt:%reg0 %r...

...dRr %R0<kill> Inspecting R0,inf = [38,46:0)[54,62:1)[94,102:2) 0 at 38-(46) 1 at 54-(62) 2 at 94-(102) and %reg1032,0.000000e+00 = [102,110:0) 0 at 102-(110): Joined. Result = R0,inf = [38,46:1)[54,62:2)[94,110:0) 0 at 94-(110) 1 at 38-(46) 2 at 54-(62) 124 %R15<def> = MOVRdRr %reg1033<kill> Inspecting %reg1033,0.000000e+00 = [110,118:1)[118,126:0) 0 at 118-(126) 1 at 110-(118) and R15,inf = [0,38:0)[126,146:1) 0 at 0*-(38) 1 at 126-(146): Joined. Result = R15,inf = [0,38:0)[110,118:2)[118,146:1) 0 at 0*-(38) 1 at 118-(146) 2 at 110-(118) 132 %R14<def> = MOVRd...