search for: allocation_order_begin

Hi! Could someone tell me the reason why allocation_order_begin method of TargetRegisterClass class takes a non-const reference to MachineFunction? I can't imagine why this method will change function and didn't find any override within llvm source which uses non-const methods of the MF parameter. Just run into compiler error because I passed a const r...

Hi Tony, It doesn't look right to me either. The "begin" and "end" methods which allocation_order_begin should return a const_iterator instead of an iterator. Those methods are "const". And, yes, the MachineFunction reference isn't even used so at the very least it could be const (if not removed). However, I'm not an expert in this area of the code. Chris or someone else will have...

Thanks, Reid. I've found that some overrides of allocation_order_begin() calls MachineFunction getInfo method. this method is not const. However, I think there could be default const implementation (const_cast of non-const method) and then allocation_order_begin() could be const. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http:...

On Wed, 16 Aug 2006, Anton Vayvod wrote: > Thanks, Reid. > I've found that some overrides of allocation_order_begin() calls > MachineFunction getInfo method. this method is not const. However, I think > there could be default const implementation (const_cast of non-const method) > and then allocation_order_begin() could be const. That sounds reasonable to me. There should probably also be a const ver...

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 m...

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'

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:...

I'm willing :) I don't know how to do it. What's "to put together a patch"? :) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060816/fb1f0b57/attachment.html>

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' and attach patch.txt to an email. If

Ok, I'm in process. Do I need to checkout the latest llvm source, first? I updated last right after the 1.8 release. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060816/fcf027c1/attachment-0001.html>

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...

...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 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,...

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

..., it was > essentially > 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 t...

...ic const unsigned Defs_Macho[] = {R0,R2,R3,R4,R5,R6,R7,R8,R9,R10,R11,R12, F0,F1,F2,F3,F4,F5,F6,F7,F8,F9,F10,F11,F12,F13, V0,V1,V2,V3,V4,V5,V6,V7,V8,V9,V10,V11,V12,V13,V14,V15,V16,V17,V18,V19, LR,CTR, CR0,CR1,CR5,CR6,CR7} GPRClass::iterator GPRClass::allocation_order_begin(const MachineFunction &MF) const { const TargetMachine &TM = MF.getTarget(); const PPCSubtarget &Subtarget = TM.getSubtarget<PPCSubtarget>(); if (Subtarget.isMachoABI()){ return Defs_Macho; } else { return Defs_ELF; } } GPRCla...

...gt;addIntervalsForSpills(*LI, *VRM, Slot); static unsigned 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: &qu...

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; > Thanks for your reply! But 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 v...

...gt; > > - When allocating registers, how do I know which register class to > > use, > > and which registers of that class are available? > 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. > > - How do I know which operands of a Machine Instruction are candidates > > for (simple) register allocation (e.g., are of type int)? > Each operand of a MachineInstr has a corresponding Machin...

...ntially 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? Ah, ok...