search for: tied0

...ressInstruction Pass; this may decide to commute the operands of the ADDSS/MULSS. It is possible to write a pass that scans through each basic block in a function looking for opportunities to fold instructions based on the following patterns: ////// B<def, tied1> = #NAME#SSrr B<kill, tied0>, A A<def, tied1> = MOVSSrr A<kill, tied0>, B<kill> ==> A<def, tied1> = #NAME#SSrr A<kill, tied0>, B<kill> ///// ///// B<def, tied1> = #NAME#PSrr B<kill, tied0>, A A<def, tied1> = MOVSSrr A<kill, tied0>, B<kill&gt...

...%T1_Z; R600_TReg32:%vreg16 %vreg15<def> = COPY %T1_Y; R600_TReg32:%vreg15 %vreg14<def> = COPY %T1_X; R600_TReg32:%vreg14 %vreg18<def> = R600_LOAD_CONST 4; R600_Reg32:%vreg18 %vreg20<def> = IMPLICIT_DEF; R600_Reg128:%vreg20 %vreg19<def,tied1> = INSERT_SUBREG %vreg20<tied0>, %vreg14, sel_x; R600_Reg128:%vreg19,%vreg20 R600_TReg32:%vreg14 %vreg2<def> = R600_LOAD_CONST 5; R600_Reg32:%vreg2 %vreg22<def> = IMPLICIT_DEF; R600_Reg128:%vreg22 %vreg21<def,tied1> = INSERT_SUBREG %vreg22<tied0>, %vreg18<kill>, sel_x; R600_Reg128:%vreg21,%vreg22...

...'ve come across a problem with register allocation which I have been unable to track down the root cause of. 6728B %vreg304<def> = COPY %vreg278; VRF128:%vreg304,%vreg278 6736B %vreg302<def> = COPY %vreg278; VRF128:%vreg302,%vreg278 6752B %vreg278<def,tied1> = foo %vreg278<tied0>, %vreg277, 14, pred:1, pred:%noreg, 5; VRF128:%vreg278 VRF64_l:%vreg277 * bar 30, %vreg278; VRF128:%vreg278 6760B %vreg302<def,tied1> = foo %vreg302<tied0>, %vreg270, 14, pred:1, pred:%noreg, 5; VRF128:%vreg302 VRF64_l:%vreg270 * bar 30, %vreg302; VRF128:%vreg302 6768B %vreg304&lt...

...Conservatively clear kill flags after coalescing. This solves the problem of having a kill flag inside a loop with a definition of the register prior to the loop: %vreg368<def> ... Inside loop: %vreg520<def> = COPY %vreg368 %vreg568<def,tied1> = add %vreg341<tied0>, %vreg520<kill> => was coalesced into => %vreg568<def,tied1> = add %vreg341<tied0>, %vreg368<kill> MachineVerifier then complained: *** Bad machine code: Virtual register killed in block, but needed live out. *** The kill flag for %vreg368 is incorrect,...

...16 > %vreg15<def> = COPY %T1_Y; R600_TReg32:%vreg15 > %vreg14<def> = COPY %T1_X; R600_TReg32:%vreg14 > %vreg18<def> = R600_LOAD_CONST 4; R600_Reg32:%vreg18 > %vreg20<def> = IMPLICIT_DEF; R600_Reg128:%vreg20 > %vreg19<def,tied1> = INSERT_SUBREG %vreg20<tied0>, %vreg14, sel_x; R600_Reg128:%vreg19,%vreg20 R600_TReg32:%vreg14 > %vreg2<def> = R600_LOAD_CONST 5; R600_Reg32:%vreg2 > %vreg22<def> = IMPLICIT_DEF; R600_Reg128:%vreg22 > %vreg21<def,tied1> = INSERT_SUBREG %vreg22<tied0>, %vreg18<kill>, sel_x; R600_Reg128:...

...do the reversal transformation. We need Live Interval information to justify the transformation, however currently live Interval information is not ready in both places. * The pattern matching looks quite ad hoc on machine IR. I need to figure out we can replace %vreg0 in "AND32ri8 %vreg0<tied0>, 31" with %vreg1 by looking at the copy chain starting from %vreg9<def> = COPY %vreg0 to %vreg1<def> = MOVZX32rr8 %vreg9 first, and at the same time, after replacing vreg0 with %vreg1, vreg0 becomes dead at the other AND32ri and we can save an instruction there. In addition, re...

...00 %vreg2; R600_Reg32:%vreg7 R600_TReg32:%vreg2 %vreg8<def> = ADD 0, 0, 1, 0, 0, 0, %vreg7<kill>, 0, 0, 0, %vreg5, 0, 0, 0, 1, pred:%PRED_SEL_OFF, 0; R600_Reg32:%vreg8,%vreg7,%vreg5 %vreg10<def> = IMPLICIT_DEF; R600_Reg128:%vreg10 %vreg9<def,tied1> = INSERT_SUBREG %vreg10<tied0>, %vreg6<kill>, sel_x; R600_Reg128:%vreg9,%vreg10 R600_Reg32:%vreg6 RESERVE_REG 1 RESERVE_REG 2 %vreg11<def,tied1> = INSERT_SUBREG %vreg9<tied0>, %vreg8<kill>, sel_y; R600_Reg128:%vreg11,%vreg9 R600_Reg32:%vreg8 %vreg13<def> = IMPLICIT_DEF; R600_Reg32:%vreg13 %vreg1...

...X<def> = MOV64rr %RSP; flags: FrameSetup Successors according to CFG: BB#1 BB#1: derived from LLVM BB %0 Predecessors according to CFG: BB#0 BB#1 OR64mi8 %RCX, 1, %noreg, 0, %noreg, 0, %EFLAGS<imp-def>; flags: FrameSetup %RCX<def,tied1> = SUB64ri32 %RCX<tied0>, 4096, %EFLAGS<imp-def>; flags: FrameSetup %RDX<def,tied1> = SUB64ri32 %RDX<tied0>, 4096, %EFLAGS<imp-def>; flags: FrameSetup JAE_1 <BB#1>, %EFLAGS<imp-use>; flags: FrameSetup Successors according to CFG: BB#2 BB#1 BB#2: derived from LLVM...

...X32>; +  let hasSideEffects = 0 in +    def RISBMux : RotateSelectRIEfPseudo<GRX32, GRX32>; The input to TwoAddress is: BB#0: derived from LLVM BB %0     Live Ins: %r2l         %vreg0<def> = COPY %r2l<kill>; GR32Bit:%vreg0         %vreg9<def,tied1> = NIFMux %vreg0<tied0>, 14, %cc<imp-def,dead>; GRX32Bit:%vreg9 GR32Bit:%vreg0         %vreg4<def,tied1> = NIFMux %vreg0<tied0>, 254, %cc<imp-def,dead>; GRX32Bit:%vreg4 GR32Bit:%vreg0         %vreg2<def> = COPY %vreg0<kill>; GR32Bit:%vreg2,%vreg0         %vreg3<def> = COP...

...e code for function main. before replace frame indices # Machine code for function main: Post SSA Frame Objects: fi#0: size=1024, align=4, at location [SP-1024] fi#1: size=1024, align=4, at location [SP-2048] BB#0: derived from LLVM BB %entry %ESP<def,tied1> = SUB32ri %ESP<tied0>, 2060, %EFLAGS<imp-def,dead>; flags: FrameSetup PROLOG_LABEL <MCSym=.Ltmp0> CALLpcrel32 <ga:@bar>, <regmask>, %ESP<imp-use>, %ESP<imp-def> %ESP<def,tied1> = ADD32ri %ESP<tied0>, 2060, %EFLAGS<imp-def,dead>...

...e a loop >>> with a definition of the register prior to the loop: >>> >>> %vreg368<def> ... >>> >>> Inside loop: >>> >>> %vreg520<def> = COPY %vreg368 >>> %vreg568<def,tied1> = add %vreg341<tied0>, %vreg520<kill> >>> >>> => was coalesced into => >>> >>> %vreg568<def,tied1> =add%vreg341<tied0>, %vreg368<kill> >>> >>> MachineVerifierthen complained: >>> *** Bad machine code: Virtual regis...

...e Interval >> information to justify the transformation, however currently live >> Interval information is not ready in both places. >> >> * The pattern matching looks quite ad hoc on machine IR. I need to >> figure out we can replace %vreg0 in "AND32ri8 %vreg0<tied0>, 31" with >> %vreg1 by looking at the copy chain starting from %vreg9<def> = COPY >> %vreg0 to %vreg1<def> = MOVZX32rr8 %vreg9 first, and at the same time, >> after replacing vreg0 with %vreg1, vreg0 becomes dead at the other >> AND32ri and we can save a...

...TION <call frame instruction> CALLpcrel32 <ga:@debugPointer>, <regmask %BH %BL %BP %BPL %BX %DI %DIL %EBP %EBX %EDI %ESI %SI %SIL>, %ESP<imp-use>, %ESP<imp-def>, %EAX<imp-def,dead>, %EDX<imp-def,dead> %ESP<def,tied1> = ADD32ri8 %ESP<tied0>, 4, %EFLAGS<imp-def,dead> CFI_INSTRUCTION <call frame instruction> PUSHi32 <ga:@foo>, %ESP<imp-def>, %ESP<imp-use> CFI_INSTRUCTION <call frame instruction> CALLpcrel32 <ga:@debugInt>, <regmask %BH %BL %BP %BPL %BX %DI...

...fore replace frame indices > # Machine code for function main: Post SSA > Frame Objects: > fi#0: size=1024, align=4, at location [SP-1024] > fi#1: size=1024, align=4, at location [SP-2048] > > BB#0: derived from LLVM BB %entry > %ESP<def,tied1> = SUB32ri %ESP<tied0>, 2060, %EFLAGS<imp-def,dead>; flags: FrameSetup > PROLOG_LABEL <MCSym=.Ltmp0> > CALLpcrel32 <ga:@bar>, <regmask>, %ESP<imp-use>, %ESP<imp-def> > %ESP<def,tied1> = ADD32ri %ESP<tied0>, 2060, %EFLAGS<imp-def,dead>...

...>> # Machine code for function main: Post SSA >> Frame Objects: >> fi#0: size=1024, align=4, at location [SP-1024] >> fi#1: size=1024, align=4, at location [SP-2048] >> >> BB#0: derived from LLVM BB %entry >> %ESP<def,tied1> = SUB32ri %ESP<tied0>, 2060, >> %EFLAGS<imp-def,dead>; flags: FrameSetup >> PROLOG_LABEL <MCSym=.Ltmp0> >> CALLpcrel32 <ga:@bar>, <regmask>, %ESP<imp-use>, %ESP<imp-def> >> %ESP<def,tied1> = ADD32ri %ESP<tied0>, 2060, %EFLAG...

...to commute > the operands of the ADDSS/MULSS. > > It is possible to write a pass that scans through each basic block in > a function looking for opportunities to fold instructions based on the > following patterns: > > ////// > B<def, tied1> = #NAME#SSrr B<kill, tied0>, A > A<def, tied1> = MOVSSrr A<kill, tied0>, B<kill> > ==> > A<def, tied1> = #NAME#SSrr A<kill, tied0>, B<kill> > ///// > > ///// > B<def, tied1> = #NAME#PSrr B<kill, tied0>, A > A<def, tied1> = MOVSSrr A...

On Tue, Jul 28, 2015 at 6:34 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Jul 28, 2015 at 2:25 AM, John Kåre Alsaker > <john.mailinglists at gmail.com> wrote: >> >> On Tue, Jul 28, 2015 at 12:44 AM, Reid Kleckner <rnk at google.com> wrote: >> > Yeah, the function attributes section of LangRef is a reasonable place >> > to >>

...> + def RISBMux : RotateSelectRIEfPseudo<GRX32, GRX32>; > > The input to TwoAddress is: > > BB#0: derived from LLVM BB %0 > Live Ins: %r2l > %vreg0<def> = COPY %r2l<kill>; GR32Bit:%vreg0 > %vreg9<def,tied1> = NIFMux %vreg0<tied0>, 14, %cc<imp-def,dead>; GRX32Bit:%vreg9 GR32Bit:%vreg0 > %vreg4<def,tied1> = NIFMux %vreg0<tied0>, 254, %cc<imp-def,dead>; GRX32Bit:%vreg4 GR32Bit:%vreg0 > %vreg2<def> = COPY %vreg0<kill>; GR32Bit:%vreg2,%vreg0 > %vreg3<def...

...a machine instruction into a following machine basic block (not necessarily a successor), even when that later block can be reached through a setjmp. Here is some example debug output from llc that I'm seeing: Sinking along critical edge. Sink instr %vreg8<def,tied1> = ADD64rr %vreg14<tied0>, %vreg31, %EFLAGS<imp-def,dead>; GR64:%vreg8,%vreg14,%vreg31 into block BB#11: Predecessors according to CFG: BB#8 BB#10 BB#32 ... EH_SjLj_Setup <BB#36>, <regmask> Successors according to CFG: BB#34 BB#36 Sinking along critical edge. Sink instr %vreg8&...

CallFrameSetupOpcode is a pseudo opcode like X86::ADJCALLSTACKDOWN64. That means when the code is expected to be called before the pseudo instructions are eliminated. I don't know why it's not the case for you. A quick look at PEI code indicates the pseudo's should not have been removed at the time when replaceFrameIndices are run. Evan On Sep 25, 2013, at 8:57 AM, Krzysztof