Travis Downs (travis.downs.delete@this.gmail.com) on December 25, 2018 3:41 pm wrote:
> Wilco (Wilco.dijkstra.delete@this.ntlworld.com) on December 22, 2018 10:24 am wrote:
> > > The result of the load doesn't need to participate in renaming
> > > in the same way because it is not architecturally
> > > visible and doesn't persist beyond the instruction. It just needs to get from the load to the single op
> > > that will ever consume it, which is a different problem and likely off the critical path.
> >
> > You could special case it since no other instruction needs to read the renamed register.
> > But other than that it's like any other destination that needs to be renamed.
>
> I don't agree. In fact, it occurs to me that you don't even need the temporary register:
> both halves of the operation can use the same physical register: the load goes into the
> register, and the operation executes against it and updates it. There are no intermediate
> operations so nothing needs to see the state after the load but before the op.
>
> However it is implemented, it is fairly clear to me that in practice on x86
> (and I suspect other archs as well although I am less familiar) the lack of
> a second output register lets these pairs be renamed efficiently as a unit.
>
>
> The alternative view is that somehow the renamer is capable of renaming two-destination
> operations, but only in the special case of fused load ops and they somehow don't expand
> that functionality to other two-destination instructions. That seems ... unlikely.
>
> > As is the flags register.
>
> Yes, flags have to be renamed, but does it matter here?
>
> In any case, one strategy to rename flags, which I believe is used on modern Intel x86, is simply to
> extend each physical register to hold the set of flags bits in addition to the reg data, so any instruction
> which has a destination register (almost all of them) uses the same physical register to hold the flags
> which result from the operation as well. The renamer tracks in-order which flags map to which physical
> register (it's often more than one on x86 because of instructions which write to a subset of flags),
> and adds as input the correct reg(s) for any instruction which consumes flags.
>
> So using that method supporting flags isn't much harder than regular renaming
> on the write side (since you are already generally allocating a physical register
> for the destination), and acts like another input on the read side.
>
>
> > All instructions must be renamed either way. Early cracking means more micro ops to
> > rename, so throughput is simply lower. Now you could widen rename, but that has a
> > high cost. A cheaper approach is to add support for a 2nd destination register.
>
> I'm not really following. The cost to rename isn't counted in instructions, I don't think,
> it's largely counted in terms of operations, input registers and output registers. You can't
> get around renaming limits simply by fusing 10 instructions into one big operation with
> 10 outputs and then pretend your renamer treats that as a single instruction!
>
> Said another way, if you can build a 6-wide single destination renamer, I don't think that implies you
> can "easily" build a 6-wide double destination renamer on the same technology with the same people. Maybe
> you can build a 3, 4 or 5 wide one though. How that all pans out depends on fraction of actually fused
> operations: if you have an instruction set that inherently has lots of double destination instructions
> (e.g., auto-increment) then maybe you favor narrower crack-at-rename. If the majority of instructions are
> single destination (see x86), maybe you favor a wider single-destination renamer and early cracking.
>
> Out of curiosity, any idea what Apple is doing in the A-series?
>
> >
> > > Note that I agree with you that rename bandwidth is saved
> > > in the case of micro-fused/uncracked-until-after
> > > rename ops like load-op on x86 or call/store on ARM. It's only for 2-output
> > > ops like auto-increment this doesn't apply.
> >
> > A modern Arm core can execute 2 loads with auto-increment every cycle using just 2 rename slots.
> > The other slots are still free for other instructions, so yes it saves rename bandwidth.
>
>
> As above, I don't think this is how it works. It's not an apples to apples comparison to compare
> a late-cracking renamer capable of handling N multi-destination instructions, with an early
> cracking one. The latter is simpler so can be wider at the same design point. I'm not saying
> one is inherently better than the other, just that it's not obvious that you can cram a ton
> of complexity into one op and then build a renamer that supports this efficiently.

I agree with Travis here. There are two pieces to renaming: source renaming and destination renaming. Source renaming (mapping source arch regs to phy regs) is mostly a read-port limitation in the aliasing table (not entirely though as we'll see below). This is somewhat "easy" as you can get more read ports through duplication of state if that's the bottleneck. The harder problem is dest arch reg to phy reg renaming and forwarding the results in the same dispatch packet. In a single cycle, you need to pop N entries out of the PRF freelist (N being the number of destinations being renamed), assign them to destination arch registers, and bypass these assignments to ops in the same dispatch group that may source the same arch reg (like add r0,r1,r2; mul r3, r0, r0 needs to rename R0 and forward the phy reg to both sources of mul ). That's basically a lot of bypassing, and grows non-linearly with destination rename width (op 1 dest may be sourced by 5 other ops in a 6-wide dispatch and each op may take 2 or even 3 sources.). The op format doesn't really matter at that point; it's just how many destinations can you rename and forward to how many sources. If you rename more destinations, you have to pop more entries out of the freelist and forward more of these to sources. It's more useful to think of the problem in terms of total number of dests and sources renamed per cycle. ARM's ldp does nothing to simplify this problem. ARM's fused arithmetic instructions do help: add with shifts and 'complex' addressing modes, as do x86's complex addressing modes and ld-op, ld-op-st, etc. Whether they are implemented as cracked ops before dispatch or post-dispatch is an implementation detail and I assume are subjected to careful tradeoff studies.