Re: AMD Bulldozer optimization guide
- From: "Andy (Super) Glew" <andy@xxxxxxxxxxxxxxxxxx>
- Date: Mon, 23 Jan 2012 10:17:33 -0800
On 1/22/2012 3:40 PM, Joe keane wrote:
One of the BAD points of RISC instruction set design is that the
compiler/assembler/programmer has to invent
constants/displacements/immediates,... Many of these displacements need
more address bits than the instruction carries naturally (16-bits
typically, 13-bits SPARC, 12-bits 360+). The lack of enough displacement
bits creates a lot of instructions that simply paste bits. Decoders are
ALREADY good at pasting bits, arguably better than instruction sets.
On the RT, r0 always points to the function's "contant pool". So if
you need a big constant (e.g. full word), you just load it from there,
normal load/store. It doesn't make any attempt of a way to get bigger
I think it's fine. You don't really miss the immediates.
Except in locore.
Nearly every OS, on machines that do not switch some registers or run on a special interrupt stack in at least some modes, have some sort of "locore" - an area of memory whose address is such that it can be constructed via an immediate WITHOUT DESTROYING ANY REGISTERS, so that you can save the registers that you would have to destroy in order to access any region of memory further afield.
Heck, quite a few have locore even if they switch registers on an event. It's always nice to have something that you can guarantee access to.
"Constant pools" - a frequently used constant in a constant pool occupies DRAM, several places in the cache (full cache line, including neighbours that you should probably arrange to access together), and the register it is currently held in. And load instructions are necessary to pull it in, costing power.
Constants embedded in the instruction stream occupy those bits in the instruction stream, howsoever many times they are used. It is likely that such large immediates can be moved to registers just as often as constant pool memory locations can be moved to registers.
So, the difference between constant pool and constants in the instruction stream are
(a) the difference between the decoder extracting the bits,
and the load instruction executing to get the bits
(b) the cost of the cache occupancy.
Oh, and there's an additional benefit to immediate constants embedded in the instruction stream: they need never occupy scheduler bandwidth, RF read port bandwidth, etc. So you would probably NOT want to optimize them to registers as often as you need to optimize constant pool values, because even if the code size may be bigger die to having replicas of the constant, the power costs are lower.
GPUs have "constant register files", and/or allow memory locations in a constant pool to be specified via a register number like field in an instruction, that is added to a base register to get the address.
Typically there are lots of swizzles and transforms available to be applied to constants, as well as "ordinary" GPU registers.
I suppose that there are some optimizations that you can create for a nearly constant register file.
Definitely, this saves a few bits on the destination register, since you don't write to constant registers (very often, and not in the instruction set - you may load and store the constant registers en masse).
You wouldn't have to rename the constants, you could just serialize when they are changed.
Constant registers aren't attached to a bypass network. However, if you are doing register file port reduction, they may participate.
- Prev by Date: Re: AMD Bulldozer optimization guide
- Next by Date: Re: Computation using real numbers as opposed to rational approximations to real numbers
- Previous by thread: Re: AMD Bulldozer optimization guide
- Next by thread: Re: AMD Bulldozer optimization guide