search for: vreg0

...reetings Matthias Am 10/8/13, 11:03 AM, schrieb Akira Hatanaka: > Hi, > > I have a question about the way sub-registers are spilled and restored > that is related to the changes I made in r192119. > > Suppose I have the following piece of code with four > instructions. %vreg0 and %vreg1 consist of two sub-registers indexed > by sub_lo and sub_hi. > > instr0 %vreg0<def> > instr1 %vreg1:sub_lo<def,read-undef> > instr2 %vreg0<use> > instr3 %vreg1:sub_hi<def> > > If register allocator decides to insert spill and restore instr...

...e an 'S' value %vreg1:ssub_1<def> = produce an 'S' value = use a 'D' value %vreg1 Problems / Motivation ===================== Currently the llvm register allocator tracks liveness for whole virtual registers. This can lead to suboptimal code: %vreg0:ssub_0<def,read-undef> = produce an 'S' value %vreg0:ssub_1<def> = produce an 'S' value = use a 'D' value %vreg0 %vreg1 = produce an 'S' value = use an 'S' value %vreg1 = use an 'S' value %vreg0:ssub_0 The current...

...to remove the side effects flag from one instruction: -  def RISBMux : RotateSelectRIEfPseudo<GRX32, GRX32>; +  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...

...atthias > > Am 10/8/13, 11:03 AM, schrieb Akira Hatanaka: > > Hi, > > I have a question about the way sub-registers are spilled and restored > that is related to the changes I made in r192119. > > Suppose I have the following piece of code with four > instructions. %vreg0 and %vreg1 consist of two sub-registers indexed by > sub_lo and sub_hi. > > instr0 %vreg0<def> > instr1 %vreg1:sub_lo<def,read-undef> > instr2 %vreg0<use> > instr3 %vreg1:sub_hi<def> > > If register allocator decides to insert spill and restore in...

...4 @xtr(i64 12345123400) #2 ret i64 %call } Which is probably the best representation to have at this relatively high level. At the machine level it looks like it is the register coalescer that is duplicating the constant. It transforms 0B BB#0: derived from LLVM BB %entry 16B %vreg0<def> = MOV64rm %RIP, 1, %noreg, <ga:@val>[TF=5], %noreg; mem:LD8[GOT] GR64:%vreg0 32B %vreg1<def> = MOV64rm %RIP, 1, %noreg, <ga:@p>[TF=5], %noreg; mem:LD8[GOT] GR64:%vreg1 48B MOV64mr %vreg1, 1, %noreg, 0, %noreg, %vreg0; mem:ST8[@p](tbaa=!"any...

...as > > Am 10/8/13, 11:03 AM, schrieb Akira Hatanaka: >> Hi, >> >> I have a question about the way sub-registers are spilled and restored that is related to the changes I made in r192119. >> >> Suppose I have the following piece of code with four instructions. %vreg0 and %vreg1 consist of two sub-registers indexed by sub_lo and sub_hi. >> >> instr0 %vreg0<def> >> instr1 %vreg1:sub_lo<def,read-undef> >> instr2 %vreg0<use> >> instr3 %vreg1:sub_hi<def> >> >> If register allocator decides to insert...

For the little C test program where a constant is stored in memory and also used as a parameter: #include <stdint.h> uint64_t val, *p; extern uint64_t xtr( uint64_t); uint64_t caller() { uint64_t x; p = &val; x = 12345123400L; *p = x; return xtr(x); } clang (3.2, 3.3 and svn) generates the following X86 code (at -O3): caller: movq

...rated by LiveIntervalAnalysis, but I don't understand why it is generated and how to avoid this counterproductive optimization. TIA, Dominique Torette. # *** IR Dump After MachineFunction Printer ***: # Machine code for function addproddivConst: Post SSA Function Live Ins: %FA_ROFF1 in %vreg0 0B BB#0: derived from LLVM BB %entry Live Ins: %FA_ROFF1 16B %vreg0<def> = COPY %FA_ROFF1; FPUaOffsetClass:%vreg0 32B %vreg2<def> = MOVSUTO_A_iSLo 1077936128; FPUaOffsetClass:%vreg2 48B %vreg3<def> = FMUL_A_oo %vreg0, %vreg2, %...

...t; } > > Which is probably the best representation to have at this relatively high level. > > At the machine level it looks like it is the register coalescer that > is duplicating the constant. It transforms > > 0B BB#0: derived from LLVM BB %entry > 16B %vreg0<def> = MOV64rm %RIP, 1, %noreg, > <ga:@val>[TF=5], %noreg; mem:LD8[GOT] GR64:%vreg0 > 32B %vreg1<def> = MOV64rm %RIP, 1, %noreg, <ga:@p>[TF=5], > %noreg; mem:LD8[GOT] GR64:%vreg1 > 48B MOV64mr %vreg1, 1, %noreg, 0, %noreg, %vreg0; > mem...

...uction: > > - def RISBMux : RotateSelectRIEfPseudo<GRX32, GRX32>; > + 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:...

...tion pass are the proper places to 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...

...y. Doing the mov->push transformation before PEI means I'd have to leave the ADJCALLSTACKDOWN/UP pair unbalanced. E.g. something like: ADJCALLSTACKDOWN32 0, %ESP<imp-def>, %EFLAGS<imp-def,dead>, %ESP<imp-use> %vreg9<def,dead> = COPY %ESP; GR32:%vreg9 PUSH32rmm %vreg0, 1, %noreg, 28, %noreg, %ESP<imp-def>, %ESP<imp-use>; GR32:%vreg0 PUSH32rmm %vreg0, 1, %noreg, 24, %noreg, %ESP<imp-def>, %ESP<imp-use>; GR32:%vreg0 PUSH32rmm %vreg0, 1, %noreg, 20, %noreg, %ESP<imp-def>, %ESP<imp-use>; GR32:%vreg0 PUSH32rmm %vreg0, 1, %noreg,...

...sters before any of the divides are scheduled. As a result, we end up with significantly higher register pressure after all the loads. -- 0B BB#0: derived from LLVM BB %entry Live Ins: %X3 %X4 16B %vreg1<def> = COPY %X4; G8RC_and_G8RC_NOX0:%vreg1 32B %vreg0<def> = COPY %X3; G8RC_and_G8RC_NOX0:%vreg0 48B %vreg2<def> = LD 0, %vreg0; mem:LD8[%num](tbaa=!4) G8RC:%vreg2 G8RC_and_G8RC_NOX0:%vreg0 64B %vreg3<def> = LD 0, %vreg1; mem:LD8[%den](tbaa=!4) G8RC:%vreg3 G8RC_and_G8RC_NOX0:%vreg1 144B %vreg7<...

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

On Oct 10, 2013, at 7:59 AM, Maurice Marks <maurice.marks at gmail.com> wrote: > I went back to this problem after looking at some other things. Turning on debugging I noticed that the register coalescer is trying to do the "right thing" and merge vreg0 (the previous load of the constant) with the first parameter of the call (%rdi), which is exactly what gcc does in this case - eliminating a second constant load, but its refusing to do the merge: > > Here's the debug output for that part of the compilation: > > ********** SIMPLE...

Hi, I am working on a simple copy propagation pass for the R600 backend that propagates immediates rather than registers. For example, I want to transform: ... %vreg1 = V_MOV_B32 1 %vreg2 = V_ADD_I32 %vreg1, %vreg0 ... into: %vreg1 = V_MOV_B32 1 ; <- Only delete this if it is dead %vreg2 = V_ADD_I32 1, %vreg0 For best results, I am trying to run this pass after the TwoAddressInstruction pass, which means I need to preserve the LiveIntervals analysis. My question is: How do I update the LiveIntervals to...

...LLVM BB %entry > %vreg5<def> = IMPLICIT_DEF; IntRegs:%vreg5 > %vreg4<def> = TFRI_V4 <ga:@xx_stack>; IntRegs:%vreg4 > Successors according to CFG: BB#1 > > BB#1: derived from LLVM BB %for.cond > Predecessors according 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 &g...

...call void @llvm.AMDGPU.store.output(float %23, i32 6)   %24 = extractelement <4 x float> %9, i32 3   call void @llvm.AMDGPU.store.output(float %24, i32 7)   ret void } # *** IR Dump Before Expand ISel Pseudo-instructions ***: # Machine code for function main: SSA Function Live Ins: %T1_W in %vreg0, %T1_Z in %vreg1, %T1_Y in %vreg2, %T1_X in %vreg3 Function Live Outs: %T1_W %T1_Z %T1_Y %T1_X %T2_W %T2_Z %T2_Y %T2_X BB#0: derived from LLVM BB %0     Live Ins: %T1_W %T1_Z %T1_Y %T1_X %vreg3<def> = COPY %T1_X; R600_TReg32:%vreg3 %vreg2<def> = COPY %T1_Y; R600_TReg32:%vreg2 %vreg1&lt...

Hi, We're having an issue with TailDuplication in our out-of-tree target and it's this PHI-node that seems to be the cause of the trouble: %vreg2<def> = PHI %vreg0, <BB#2>, %vreg1, <BB#3>; rN:%vreg2 aNlh_0_7:%vreg0 aNlh_rN:%vreg1 Note that the defined %vreg2 has register class "rN" while the read %vreg0 has register class "aNlh_0_7". "rN" and "aNlh_0_7" are disjoint. Is such a PHI node ok? If it is, the...

...it seems to improve .debug_loc range validity and enhance the debugging experience for optimized code. The problem that I see with this approach is that DEBUG_VALUEs are only valid until the next DEBUG_VALUE that describes the same variable. How does your pass handle: BB0: DEBUG_VALUE “x”, vreg0 | | | BB1: | DEBUG_VALUE “x”, vreg1 | | \_____BB2: | | |____/ BB2: vreg0 // still not clobbered here. Does it insert a DEBUG_VALUE “x”, vreg0 into BB2? -- adrian