search for: reg_v

...if am wrong, but, you still have to allocate physical registers to them, because their values must be reloaded before been used. But after you spill a register, you break its live ranges, so, each use of that register can be loaded into a different physical. In my register allocator, after I spill reg_v: For each use of reg_v: create a new reg_v' replace reg_v by reg_v' If the instruction containing reg_v' hasn't been scanned by the register allocator, when it happens, reg_v' will receive a physical register. You must assign to reg_v' a weight such that is is not...

On 8/7/06, Chris Lattner <sabre at nondot.org> wrote: > > On Sun, 6 Aug 2006, Anton Vayvod wrote: > > I'm developing a register allocator that works iteratively. It spills > some > > virtual registers on each iteration until all the rest have physical > ones > > assigned. > > Take a look at the linear scan allocator. It is also iterative: it uses >

...s to them. Is it possible to assign physical register to the virtual > one which has a stack slot already? > Yes. The stack slot is the place where the value will be stored in memory, but, when that value is effectively used in the code, you must load it into a physical register. Assume that reg_v is mapped to stack slot x, and there is an instruction such as add reg_1 := reg_v reg_2, where reg_1 is mapped to phys_1, reg_v is mapped to phys_v, and reg_2 is mapped to phys_2. Your final code will be like: load phys_v, x add phys_1 := phys_v, phys_2 In order to insert load/store instructions,...

...ou still have to allocate > physical registers to them, because their values must be reloaded before > been used. But after you spill a register, you break its live ranges, so, > each use of that register can be loaded into a different physical. In my > register allocator, after I spill reg_v: > > For each use of reg_v: > create a new reg_v' > replace reg_v by reg_v' > > If the instruction containing reg_v' hasn't been scanned by the register > allocator, when it happens, reg_v' will receive a physical register. You > must assign to reg_...

...assign physical register to the virtual >> one which has a stack slot already? >> > > Yes. The stack slot is the place where the value will be stored in memory, > but, when that value is effectively used in the code, you must load it > into a physical register. Assume that reg_v is mapped to stack slot x, and > there is an instruction such as add reg_1 := reg_v reg_2, where reg_1 is > mapped to phys_1, reg_v is mapped to phys_v, and reg_2 is mapped to > phys_2. Your final code will be like: > > load phys_v, x > add phys_1 := phys_v, phys_2 > > In...

overall the same as the old stuff, but with better namings and tirivialy improved code here and there Karol Herbst (9): pci: add gk104 variant pci: add gf106 variant pci: implement generic code for PCIe speed change pci: implement pcie speed change for tesla pci: implement pcie speed change on Fermi pci: implement PCIe speed change for kepler+ bios/perf: parse the pci speed from the

I'm not sure about one thing: you assign stack slot to each new register you replace the spilled one with. And then you need to allocate physical registers to them. Is it possible to assign physical register to the virtual one which has a stack slot already? On 8/21/06, Fernando Magno Quintao Pereira <fernando at cs.ucla.edu> wrote: > > > > So what addIntervalsToSpills

this patch series implements PCIe speed changes for Tesla and newer. The Kepler and Fermi bits are tested on my cards at home. Karol Herbst (9): pci: add gk104 variant pci: add gf106 variant pci: implement generic code for PCIe speed change pci: implement pcie speed change for tesla pci: implement pcie speed change on Fermi pci: implement PCIe speed change for kepler+ bios/perf:

overall it is for the most part the same as my older version. I cleaned up some copyright things, so that it is more like the others. Also I moved the print about the max speed supported into preinit and did some other minor cleanups in the 3rd commit. Happy testing (and performance for prime offloading setups) Karol Herbst (9): pci: add gk104 variant pci: add gf106 variant pci: implement