search for: ld4

...reg *never* overlap. Therefore, vector loads are lowered to scalar loads followed by a chain of INSERT_VECTOR_ELTs. Then we select those to INSERT_SUBREG, everything fine to that point. Status before live analisys is (non-related instrs removed): 36 %reg16388<def> = LDWr %reg16384, 0; mem:LD4[<unknown>] 68 %reg16392<def> = INSERT_SUBREG %reg16392<undef>, %reg16388<kill>, 1 76 %reg16394<def> = LDWr %reg16386<kill>, 0; mem:LD4[<unknown>] 116 %reg16400<def> = MOVEV %reg16392<kill> 124 %reg16400<def> = INSERT_SUBREG %reg16400, %reg...

...Constant<4> [ID=-3] 0x3e7e2f0: <multiple use> 0x3ea6d00: <multiple use> 0x3ea7120: <multiple use> 0x3ea7228: i32 = add 0x3ea6d00, 0x3ea7120 [ORD=5] [ID=-3] 0x3ea45e0: <multiple use> 0x3ea7540: i32,ch = load 0x3e7e2f0, 0x3ea7228, 0x3ea45e0<LD4[%a+12]> [ORD=5] [ID=-3] 0x3e7e2f0: <multiple use> 0x3ea6d00: <multiple use> 0x3ea45e0: <multiple use> 0x3ea7648: i32,ch = load 0x3e7e2f0, 0x3ea6d00, 0x3ea45e0<LD4[%a+8]> [ORD=5] [ID=-3] 0x3e7e2f0: <multiple use> 0x3ea43d0: <multiple use&...

...ns 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 reasons they need to be removed? Would it break something if both Ma...

After PrologEpilogCodeInserter I found that the instructions that restore callee saved registers S0,S1,LR are in the wrong location ,the instructions are: %S0<def> = LD %SP, 36; mem:LD4[FixedStack2] %S1<def> = LD %SP, 40; mem:LD4[FixedStack1] %LR<def> = LD %SP, 44; mem:LD4[FixedStack0] (LR is the Return address register) the whole code of print-machineinstrs are: # After PrologEpilogCodeInserter: # Machine code for function L_mpy_ls: Post SSA BB#0: derived from LLVM BB...

...4[%retval] SwRxRyOffMemX16 %V0<kill>, %SP, 20; mem:ST4[%i] PHI <BB#1> Successors according to CFG: BB#1 BB#2: derived from LLVM BB %for.body Live Ins: %S0 Predecessors according to CFG: BB#1 %A0<def> = LwRxRyOffMemX16 %S0, <ga:@.str>[TF=2]; mem:LD4[<unknown>] %V0<def> = LwRxRyOffMemX16 %S0, <ga:@printf>[TF=3]; mem:LD4[GOT] %A1<def> = LwRxRyOffMemX16 %SP, 20; mem:LD4[%i] %T9<def> = Move32R16 %V0 %A0<def,tied> = AddiuRxRxImmX16 %A0<tied>, <ga:@.str>[TF=6] %GP<def> =...

...lizeDAG, which calls my custom LowerLOAD() and LowerSTORE() routines (which emit between 1 and O(10) SDValues, depending on alignment information), and then runs DAGCombine. To lower an i16 STORE that is known to be in the high-addressed 2 bytes of a word on my little-endian target, I emit and LD4 from the word-aligned address and an SRL 16 to shift the i16 into the LSbits of the register. DAGCombine visit()s an ISD::SRL node and notices that it is right-shifting the result of an LD4 from %arrayidx4 by 16 bits, and replaces it with an LD2 from %arrayidx+2. Replaces -------- 0x17f7070: i...

...erands 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 reasons they need to be removed? >...

...t;; > > BB#8: > Live Ins: %LR %R0 %R1 %R2 %R4 %R5 %R6 %R7 %R8 %R9 %R10 %R12 > Predecessors according to CFG: BB#7 > STRi12 %R6, %R7<kill>, 4, pred:14, pred:%noreg; mem:ST4[%__size_.i3.i.i.i.i] > %R6<def> = LDRrs %R4, %R6<kill>, 16386, pred:14, pred:%noreg; mem:LD4[%0] > BX %R6<kill> > > BB#9: > Live Ins: %LR %R0 %R1 %R2 %R4 %R5 %R6 %R7 %R8 %R9 %R10 %R12 > Predecessors according to CFG: BB#7 > STRBi12 %R6, %R7<kill>, 0, pred:14, pred:%noreg; mem:ST1[%21](align=4) > %R6<def> = LDRrs %R4, %R6<kill>, 16386, pred:1...

...owerLOAD() and >> LowerSTORE() routines (which emit between 1 and O(10) SDValues, >> depending on alignment information), and then runs DAGCombine. To lower >> an i16 STORE that is known to be in the high-addressed 2 bytes of a word >> on my little-endian target, I emit and LD4 from the word-aligned address >> and an SRL 16 to shift the i16 into the LSbits of the register. >> >> DAGCombine visit()s an ISD::SRL node and notices that it is >> right-shifting the result of an LD4 from %arrayidx4 by 16 bits, and >> replaces it with an LD2 from %ar...

On Jul 28, 2010, at 12:25 PM, Carlos Sánchez de La Lama wrote: > Which after register coalescing gets transformed into: > > 36 %reg16404:1<def> = LDWr %reg16384, 0; mem:LD4[<unknown>] > 76 %reg16394<def> = LDWr %reg16386<kill>, 0; mem:LD4[<unknown>] > 124 %reg16404<def> = INSERT_SUBREG %reg16404, %reg16394<kill>, 2 > 132 %reg16401<def> = LDWr %reg16390<kill>, 0; mem:LD4[<unknown>] > 172 %reg16404<def...

...alls my custom LowerLOAD() and > LowerSTORE() routines (which emit between 1 and O(10) SDValues, > depending on alignment information), and then runs DAGCombine.  To lower > an i16 STORE that is known to be in the high-addressed 2 bytes of a word > on my little-endian target, I emit and LD4 from the word-aligned address > and an SRL 16 to shift the i16 into the LSbits of the register. > > DAGCombine visit()s an ISD::SRL node and notices that it is > right-shifting the result of an LD4 from %arrayidx4 by 16 bits, and > replaces it with an LD2 from %arrayidx+2. > >...

...cording to CFG: BB#0 BB#1 > %vreg0<def> = PHI %vreg4, <BB#0>, %vreg3, <BB#1>; IntRegs:%vreg0,%vreg4,%vreg3 > %vreg1<def> = PHI %vreg5, <BB#0>, %vreg2, <BB#1>; IntRegs:%vreg1,%vreg5,%vreg2 > %vreg2<def> = LDriw %vreg0<kill>, 0; mem:LD4[%stack.0.in] IntRegs:%vreg2,%vreg0 > %vreg3<def> = ADD_ri %vreg2, 8; IntRegs:%vreg3,%vreg2 > %vreg6<def> = CMPEQri %vreg2, 0; PredRegs:%vreg6 IntRegs:%vreg2 > JMP_cNot %vreg6<kill>, <BB#1>, %PC<imp-def>; PredRegs:%vreg6 > JMP <BB#2> &g...

.... > > > > 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...

...6\xor.ll # Machine code for function test3: Frame Objects: fi#-2: size=4, align=4, fixed, at location [SP+8] fi#-1: size=4, align=8, fixed, at location [SP+4] Function Live Outs: %EAX BB#0: derived from LLVM BB %entry %reg16385<def> = MOV32rm <fi#-2>, 1, %reg0, 0, %reg0; mem:LD4[FixedStack-2] GR32:%reg16385 %reg16384<def> = MOV32rm <fi#-1>, 1, %reg0, 0, %reg0; mem:LD4[FixedStack-1] GR32:%reg16384 %reg16388<def> = MOV32ri 1; GR32:%reg16388 %reg16392<def> = XOR32ri %reg16385, 4294967294, %EFLAGS<imp-def>; GR32:%reg16392,1638...

...eg4, <BB#0>, %vreg3, <BB#1>; IntRegs:%vreg0,%vreg4,%vreg3 %vreg1<def> = PHI %vreg5, <BB#0>, %vreg2, <BB#1>; IntRegs:%vreg1,%vreg5,%vreg2 <<<<<<<<<<< Use of that dummy value. %vreg2<def> = LDriw %vreg0<kill>, 0; mem:LD4[%stack.0.in] IntRegs:%vreg2,%vreg0 By the time it has gotten to the scheduler, it became this: BB#0: derived from LLVM BB %entry %vreg9<def> = TFRI_V4 <ga:@xx_stack>; IntRegs:%vreg9 Successors according to CFG: BB#1 BB#1: derived from LLVM BB %for.cond Pred...

...gt;>> LowerSTORE() routines (which emit between 1 and O(10) SDValues, >>> depending on alignment information), and then runs DAGCombine.  To lower >>> an i16 STORE that is known to be in the high-addressed 2 bytes of a word >>> on my little-endian target, I emit and LD4 from the word-aligned address >>> and an SRL 16 to shift the i16 into the LSbits of the register. >>> >>> DAGCombine visit()s an ISD::SRL node and notices that it is >>> right-shifting the result of an LD4 from %arrayidx4 by 16 bits, and >>> replaces it...

...)... R4 = [0B,32r:0)[384r,416r:4)... R5 = [0B,32r:0)[400r,416r:4)... I schedule the following instruction (48B): 0B BB#0: derived from LLVM BB %entry Live Ins: %R0 %R1 %D1 %D2 8B %vreg27<def> = COPY %R1<kill>; IntRegs:%vreg27 12B %vreg30<def> = LDriw <fi#-1>, 0; mem:LD4[FixedStack-1](align=8) IntRegs:%vreg30 20B %vreg31<def> = LDriw <fi#-2>, 0; mem:LD4[FixedStack-2] IntRegs:%vreg31 24B %vreg26<def> = COPY %R0<kill>; IntRegs:%vreg26 28B %vreg106<def> = TFRI 16777216; IntRegs:%vreg106<<<<<<<<<<<<&l...

...;BB#0>, %vreg3, <BB#1>; IntRegs:%vreg0,%vreg4,%vreg3 > %vreg1<def> = PHI %vreg5, <BB#0>, %vreg2, <BB#1>; IntRegs:%vreg1,%vreg5,%vreg2 <<<<<<<<<<< Use of that dummy value. > %vreg2<def> = LDriw %vreg0<kill>, 0; mem:LD4[%stack.0.in] IntRegs:%vreg2,%vreg0 > > > By the time it has gotten to the scheduler, it became this: > > BB#0: derived from LLVM BB %entry > %vreg9<def> = TFRI_V4 <ga:@xx_stack>; IntRegs:%vreg9 > Successors according to CFG: BB#1 > > BB#1: deri...

...> I schedule the following instruction (48B): > > 0B BB#0: derived from LLVM BB %entry > Live Ins: %R0 %R1 %D1 %D2 > 8B %vreg27<def> = COPY %R1<kill>; IntRegs:%vreg27 > 12B %vreg30<def> = LDriw <fi#-1>, 0; > mem:LD4[FixedStack-1](align=8) IntRegs:%vreg30 > 20B %vreg31<def> = LDriw <fi#-2>, 0; mem:LD4[FixedStack-2] > IntRegs:%vreg31 > 24B %vreg26<def> = COPY %R0<kill>; IntRegs:%vreg26 > 28B %vreg106<def> = TFRI 16777216; > IntRegs:...

..., Constant:i32<256>, FrameIndex:i32<2>, undef:i32 t10: ch = store<ST4[%dir]> t7, ConstantFP:f32<-1.000000e+00>, FrameIndex:i32<3>, undef:i32 t12: ch = store<ST4[%m]> t10, Constant:i32<0>, FrameIndex:i32<19>, undef:i32 t13: i32,ch = load<LD4[%sz]> t12, FrameIndex:i32<2>, undef:i32 t15: ch = store<ST4[%j]> t13:1, t13, FrameIndex:i32<16>, undef:i32 t17: ch = store<ST4[%le]> t15, t13, FrameIndex:i32<14>, undef:i32 Optimized lowered selection DAG: BB#0 'main:entry' SelectionDAG has 18 nodes:...