search for: allocation_order_end

...> Ah, ok. In that case, you want to put all of the registers in one register > file, and not make the constant register allocatable (e.g. see > X86RegisterInfo.td, and note how the register classes include EBP and ESP, > but do not register allocate them (through the definition of > allocation_order_end()). > > -Chris Hope I understand you correctly: def C0 : ConstFpReg<0, "c0">; ... def C200 : ConstFpReg<199, "c200">; def I0 : ConstIntReg<0, "i0">; ... def I100 : ConstIntReg<100, "i100">; def R0 : TempReg<0, "r0&qu...

...ere > Execute(); Ah, ok. In that case, you want to put all of the registers in one register file, and not make the constant register allocatable (e.g. see X86RegisterInfo.td, and note how the register classes include EBP and ESP, but do not register allocate them (through the definition of allocation_order_end()). -Chris -- http://nondot.org/sabre/ http://llvm.org/

2005/7/23, Chris Lattner <sabre at nondot.org>: > > What does a 'read only' register mean? Is it a constant (e.g. returns > 1.0)? Otherwise, how can it be a useful value? Yes, it's a constant register. Because the instruction cannot contain an immediate value, a constant value may be stored in a constant register, and it's defined _before_ the program starts by

The target description .td files are allowed to change the default allocation order on a register class by overriding the allocation_order_begin() and allocation_order_end() methods on TargetRegisterClass. Previously, this was used all the time to filter out stack and frame pointers and other reserved registers. I was able to remove most of these custom allocation orders in the tree because the register allocators are now filtering out the reserved registers. A few...

...ur solution to this? > > I allocated spill intervals at the beginning of each iteration so all the > rest intervals (except of physreg intervals) were uncolored at the moment. > So the only difference in allocating regs for spills was what end to > choose: allocation_order_begin() or allocation_order_end(), I chose the > former. I understand that sometimes you can prefer one register over > another for spill so it won't conflict with as much intervals as it would > being mapped to another phys, but the same can be said about every > interval, right? Ah, ok, that makes sense. Yes,...

...is used I can assign it easily. I know about alias register and those are taken care of ever so cleverly. Is this because you want to control the order in which the physical registers are allocated? If so, it'll normally be better to use the TargetRegisterClass::allocation_order_begin() and allocation_order_end() functions to control that. These can be overridden directly in the .td file (see the ARMRegisterInfo.td file for examples) if you want. Other pieces of the compiler also use those iterators to walk the available registers in a register class for local allocation needs, so it's best to keep th...

...// Volatile [R0, R1, R2, R3, R4, R5, R6, R7, R8, R9, R10, R11, R12, R13, R14, R15, R16, R17, R18, R19, R20, R21, R22, R23, R24, R25, R26, R27, R28, R29, R30, R31]> { let MethodProtos = [{ iterator allocation_order_begin(const MachineFunction &MF) const; iterator allocation_order_end(const MachineFunction &MF) const; }]; let MethodBodies = [{ DLXRegsClass::iterator DLXRegsClass::allocation_order_end(const MachineFunction &MF) const { return begin() + 1; // dont allocate r0, it always contains zero } DLXRegsClass::iterator DLXRegsClass::allocation_order_end(co...

Thanks, Ralph, this line worked well :) Here it is, my first patch to LLVM :) I've changed all allocation_order_begin() and allocation_order_end() methods to take const MachineFunction &MF as a parameter. I also added const version of MachineFunction::getInfo<Ty>() method. And I changed three static hasFP() functions to take const reference to MachineFunction. While doing this I've found that some methods of MachineFunction a...

...e by the // register allocator - the floating point stackifier is responsible // for transforming FPn allocations to STn registers) def RST : RegisterClass<"X86", [f64], 32, [ST0, ST1, ST2, ST3, ST4, ST5, ST6, ST7]> { let MethodProtos = [{ iterator allocation_order_end(const MachineFunction &MF) const; }]; let MethodBodies = [{ RSTClass::iterator RSTClass::allocation_order_end(const MachineFunction &MF) const { return begin(); } }]; } Is the "begin()" in there correct? Or should it maybe be "end()"? Tha...

...right? When your algorithm finds out during one iteration that it should spill some interval it checks whether this interval is marked. If it is marked what's happening? Choosing some neighbour interval to spill instead of that one? Is this better then precoloring spill intervals (starting from allocation_order_end phys reg)? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070807/7b49e1f5/attachment.html>

Hi Chris, > On Wed, 16 Aug 2006, Anton Vayvod wrote: > > I'm willing :) I don't know how to do it. What's "to put together a > > patch"? :) > > In your local CVS tree, change the methods to be const, and adjust any > code that is neccesary for that to work. Once that is done, from the > top level, type 'cvs diff -u >& patch.txt'

It's not too much of a problem then. I can make a DenseMap between the registers and my registers. It's just one more intermediate step for a lookup. I wish to mimic all the of the registers on the machine with my std::vector<RegisterInfo> RegisterIndexes; vector. Then when a register is used I can assign it easily. I know about alias register and those are taken care of ever so

...fined registers, which is checked in the attatched patch1. This works fine for me, however on X86 the EFLAGS register is not marked non-allocatable (patch2). Is this intentional? Our backend handles condition codes pretty much like X86 and I remember I didn't get it to work without defining the allocation_order_end() function in RegisterInfo.td Anyway, I have no idea if this solution is ok for the general case, maybe the implicit defs information should rather be put into the SDeps when they are created? Regards, Christian -- please ignore: CONFIDENTIAL NOTICE: The contents of this message, includin...

...t; random. What was your solution to this? I allocated spill intervals at the beginning of each iteration so all the rest intervals (except of physreg intervals) were uncolored at the moment. So the only difference in allocating regs for spills was what end to choose: allocation_order_begin() or allocation_order_end(), I chose the former. I understand that sometimes you can prefer one register over another for spill so it won't conflict with as much intervals as it would being mapped to another phys, but the same can be said about every interval, right? > > As for giving the best result. If assumed...

...;MF) const { const TargetMachine &TM = MF.getTarget(); const PPCSubtarget &Subtarget = TM.getSubtarget<PPCSubtarget>(); if (Subtarget.isMachoABI()){ return Defs_Macho; } else { return Defs_ELF; } } GPRClass::iterator GPRClass::allocation_order_end(const MachineFunction &MF) const { const TargetMachine &TM = MF.getTarget(); const MRegisterInfo *RI = TM.getRegisterInfo(); const PPCSubtarget &Subtarget = TM.getSubtarget<PPCSubtarget>(); GPRClass::iterator I; if (Subtarget.isMachoABI()) { I...

...ed J = 0; for (unsigned I = 0; I < Added.size(); ++I, ++J) { unsigned VReg = Added[I]->reg; const TargetRegisterClass* RC = MF->getSSARegMap()->getRegClass(VReg); TargetRegisterClass::const_iterator Iter = RC->allocation_order_begin(*MF); if (Iter + J >= RC->allocation_order_end(*MF)) J = 0; unsigned PReg = *(Iter + J); // **** Assign the newly-created live interval to a physical register VRM->assignVirt2Phys(VReg, PReg); PRT->addRegUse(PReg); DEBUG(std::cerr << "\tAdded LI: " << *Added[I] << &quot...

...> Ah, ok. In that case, you want to put all of the registers in one register > file, and not make the constant register allocatable (e.g. see > X86RegisterInfo.td, and note how the register classes include EBP and ESP, > but do not register allocate them (through the definition of > allocation_order_end()). > > -Chris > > -- > http://nondot.org/sabre/ > http://llvm.org/ > -- Tzu-Chien Chiu, 3D Graphics Hardware Enginner, <URL:http://www.csie.nctu.edu.tw/~jwchiu>

On Monday 06 August 2007 12:15, Anton Vayvod wrote: > Spill intervals must be precolored because they can't be spilled once more. > They are the shortest intervals precisely over each def/use of the original > interval. That is why they also have their weights set to #INF. Yes, that's true. But I wonder if we shouldn't be smarter about which register we pick to color it.

...t I'm confused about the above. In > particular, another reply said the following: > >> For each virtual register the >> MachineRegisterInfo::getRegClass(<vreg>) method will give you a >> TargetRegisterClass. You can use the allocation_order_begin/ >> allocation_order_end methods to iterate over the allocable physregs >> in that class. > > If I can get the appropriate physical register for each virtual one > this way, then how does X86's use of sub-registers complicate my > register-allocation code? Each virtual register has an assigned...

On Thu, 17 Aug 2006, Anton Vayvod wrote: > Thanks, Ralph, this line worked well :) > Here it is, my first patch to LLVM :) > I've changed all allocation_order_begin() and allocation_order_end() methods > to take const MachineFunction &MF as a parameter. I also added const version > of MachineFunction::getInfo<Ty>() method. And I changed three static hasFP() > functions to take const reference to MachineFunction. Looks great, applied: http://lists.cs.uiuc.edu/piperma...