search for: sreg_32

...ing schedule they are often placed right next to their uses like this: 1784B %140:vgpr_32 = IMAGE_SAMPLE_LZ_V1_V2 %533:vreg_64, %30:sreg_256, %26:sreg_128, 8, 0, 0, 0, 0, 0, 0, 0, 0, implicit $exec :: (dereferenceable load 4 from custom TargetCustom8) 1792B %142:vgpr_32 = V_MUL_F32_e32 %44:sreg_32, %140:vgpr_32, implicit $exec ... 1784B %140:vgpr_32 = IMAGE_SAMPLE_LZ_V1_V2 %533:vreg_64, %30:sreg_256, %26:sreg_128, 8, 0, 0, 0, 0, 0, 0, 0, 0, implicit $exec :: (dereferenceable load 4 from custom TargetCustom8) 1792B %142:vgpr_32 = V_MUL_F32_e32 %44:sreg_32, %140:vgpr_32, implicit $exec...

...rgName=y)"). However, this is _not_ how >$names work! > >Their most prominent application is for instruction selection pattern >matching, e.g. taken at random from AMDGPU/SOPInstructions.td: > >def : GCNPat < > (i32 (smax i32:$x, (i32 (ineg i32:$x)))), > (S_ABS_I32 SReg_32:$x) >>; > >The $x is _not_ the name of the argument to smax, ineg, or S_ABS_I32. >For example, if you look at how S_ABS_I32 is defined, you'll see that >its input operand is called $src0. > >Instead, the name allows us to tie three locations in the DAG together >for p...

...> > like this: > > > > 1784B %140:vgpr_32 = IMAGE_SAMPLE_LZ_V1_V2 %533:vreg_64, > > %30:sreg_256, %26:sreg_128, 8, 0, 0, 0, 0, 0, 0, 0, 0, implicit $exec > > :: (dereferenceable load 4 from custom TargetCustom8) > > 1792B %142:vgpr_32 = V_MUL_F32_e32 %44:sreg_32, %140:vgpr_32, implicit $exec > > ... > > 1784B %140:vgpr_32 = IMAGE_SAMPLE_LZ_V1_V2 %533:vreg_64, > > %30:sreg_256, %26:sreg_128, 8, 0, 0, 0, 0, 0, 0, 0, 0, implicit $exec > > :: (dereferenceable load 4 from custom TargetCustom8) > > 1792B %142:vgpr_32 = V_MUL...

...d units in the hardware. There is 1 load unit that can hold up to 31 loads waiting to be executed, but only 1 load can be executed at a time. Pick Top CLUSTER Scheduling SU(43) %vreg46<def> = S_BUFFER_LOAD_DWORD_IMM %vreg9, 48; mem:LD4[<unknown>] SGPR_32:%vreg46 SReg_128:%vreg9 SReg_32: 45 > 44(+ 0 livethru) VS_32: 51 > 18(+ 0 livethru) Ready @46c HWLGKM +1x105u TopQ.A BotLatency SU(43) 78c *** Max MOps 1 at cycle 46 Cycle: 47 TopQ.A TopQ.A @47c Retired: 47 Executed: 47c Critical: 47c, 47 MOps ExpectedLatency: 10c - Latency limited. BotQ.A RemLatency SU(...

I included the ability to get/set an operand by name because I thought it would be easier to copy+modify an existing DAG by specifying the name of the operand you want to replace rather than having to remember its position. For example, if you want to replace the first source, isn't it easier to specify $src than remember it's the second operand? Perhaps the people actually coding these

Hi, I have a program with over 100 loads (each with a 10 cycle latency) at the beginning of the program, and I can't figure out how to get the machine scheduler to intermix ALU instructions with the loads to effectively hide the latency. It seems the issue is with load clustering. I restrict load clustering to 4 at a time, but when I look at the debug output, the loads are always being

...gt;> > >> >Their most prominent application is for instruction selection pattern >> >matching, e.g. taken at random from AMDGPU/SOPInstructions.td: >> > >> >def : GCNPat < >> > (i32 (smax i32:$x, (i32 (ineg i32:$x)))), >> > (S_ABS_I32 SReg_32:$x) >> >>; >> > >> >The $x is _not_ the name of the argument to smax, ineg, or S_ABS_I32. >> >For example, if you look at how S_ABS_I32 is defined, you'll see that >> >its input operand is called $src0. >> > >> >Instead, the name...