search for: virtregmap

I'm trying to piece together a few assignments for a graduate-level compilers class using LLVM; among these is a register allocator. I'd like to provide a register allocator that, given a partially-allocated VirtRegMap, will perform trivial register allocation (as in RegAllocSimple) on the remaining, unmapped virtual registers. To make a long story short, I want to map a single virtual register to various physical registers at different times, keeping the relevant value in memory all along. Can VirtRegMap do...

...RC.getRawAllocationOrder(MF).front(); ... VRM.assignVirt2Phys(LI.reg, PReg); The documentation for TargetRegisterClass::getRawAllocationOrder() notes that the collection may include reserved registers. So it seems that the PBQP allocator may insert a reserve physical register into the VirtRegMap. I'm not sure which component should be fixed. Is it fair to say that no-reserved-registers is an invariant of VirtRegMap? If so, shouldn't that invariant be enforced in VirtRegRewriter::assignVirt2Phys() ? Should PBQP iterate over the allocation order collection to find an un-reserved...

...Reason: KERN_INVALID_ADDRESS at address: 0x80000004 0x94abb19c in std::_Rb_tree_rebalance_for_erase () (gdb) where #0 0x94abb19c in std::_Rb_tree_rebalance_for_erase () #1 0x0073dd40 in std::_Rb_tree<llvm::MachineInstr*, std::pair<llvm::MachineInstr* const, std::pair<unsigned int, llvm::VirtRegMap::ModRef> >, std::_Select1st<std::pair<llvm::MachineInstr* const, std::pair<unsigned int, llvm::VirtRegMap::ModRef> > >, std::less<llvm::MachineInstr*>, std::allocator<std::pair<llvm::MachineInstr* const, std::pair<unsigned int, llvm::VirtRegMap::ModRef> &gt...

On Sep 19, 2008, at 2:41 AM, Matt Elder wrote: > I'm trying to piece together a few assignments for a graduate-level > compilers class using LLVM; among these is a register allocator. I'd > like to provide a register allocator that, given a partially-allocated > VirtRegMap, will perform trivial register allocation (as in > RegAllocSimple) on the remaining, unmapped virtual registers. > > To make a long story short, I want to map a single virtual register to > various physical registers at different times, keeping the relevant > value in memory all alon...

Hi Evan, > Ok. Everyone has different idea about "easy". :-) I second your opinion that it is not very easy to use and it is very tightly coupled with the current linear scan register allocator implementation. > But VirtRegMap is going to be remove one of these days. When are you going to do that? Are you going to remove it from the source tree? Will it be replaced with something similar, e.g. with another kind of spiller and register tracking mechamism? Please keep in mind that some other allocators being currently...

On Friday 19 September 2008 11:37, Evan Cheng wrote: > Please avoid using VirtRegMap. It's very tied to the current register > allocation pieces and not easily reusable. One of my mission in life > is to kill it. Im surprised to see this. I found it rather easy to re-use for custom register allocators. -Dave

Hi Susan, I'm having trouble reproducing that error on my end, but I think the problem is probably that you're not using the VirtRegRewriter infrastructure. What your allocator needs to do is populate the virtual register mapping (VirtRegMap pass) with your allocation, rather than rewriting the registers directly through MachineRegisterInfo. Have your allocator require and preserve the VirtRegMap pass, then in your runOnMachineFunction pass grab a reference to the pass with: VirtRegMap &vrm = getAnalysis<VirtRegMap>(); You...

I just updated from upstream llvm as of about last Thursday and I'm getting a segfault in VirtRegMap::RemoveMachineInstrFromMaps. It seems that the particular instruction being removed happens to reference an object at stack slot 4. The first spilled register is assigned stack slot 6 so LowSpillSlot == 6. Then, when we try to erase from SpillSlotToUsesMap, we index with a negative number. The i...

...can spills an interval and one of the intervals created (%reg1631) gets mark as rematerializable by LiveIntervals: 00984 if (CreatedNewVReg) { 00985 if (DefIsReMat) { 00986 vrm.setVirtIsReMaterialized(NewVReg, ReMatDefMI/*, CanDelete*/); 00987 if (ReMatIds[VNI->id] == VirtRegMap::MAX_STACK_SLOT) { 00988 // Each valnum may have its own remat id. 00989 ReMatIds[VNI->id] = vrm.assignVirtReMatId(NewVReg); Linear scan dutifully assigns %reg1631 to AL. Then SimpleSpiller runs and does this: 00261 unsigned VirtReg = MO.getReg(); 00262...

...two versions: one maps *every* vreg, and the other only maps those for which MRI->reg_empty(vreg) returns false. In both cases I get a core dump somewhere after my reg-allocation pass has run (when I use the "tst.c" file that I sent last time as input). Note also that there is no VirtRegMap.h in the "include" directory of my installed llvm-3.1. I had to copy that file from the source directory. That seems suspicious. Any thoughts? Thanks! Susan On 10/31/2012 07:51 PM, Lang Hames wrote: > Hi Susan, > > I'm having trouble reproducing that error on my end,...

Hello LLVMers! I recently added a generic machine rewriter/spiller that global register allocator writers may find useful. The API provided is the free function: void eliminateVirtRegs(MachineFunction&, const VirtRegMap&) declared in lib/CodeGen/VirtRegMap.h and implemented in lib/CodeGen/VirtRegMap.cpp. This function rewrites the machine code of MachineFunction to eliminate virtual registers and adds spill code as specified by VirtRegMap. VirtRegMap provides a mapping from virtual registers to physical r...

On May 8, 2008, at 11:36 AM, David Greene wrote: > I just updated from upstream llvm as of about last Thursday and I'm > getting a segfault in VirtRegMap::RemoveMachineInstrFromMaps. > It seems that the particular instruction being removed happens > to reference an object at stack slot 4. The first spilled register is > assigned stack slot 6 so LowSpillSlot == 6. Then, when we try to > erase from SpillSlotToUsesMap, we index with a neg...

...stack slot reference like this before register allocation? > > Basically, I'm > > Codegen can definitely create stack slots during isel lowering. I > don't think you can assume all non-fixed slots are created during > register allocation. Ok, so isn't there a bug in VirtRegMap::RemoveMachineInstrFromMaps since it assumes every stack index is >= LowSpillSlot, which doesn't get set until regalloc spill time? -Dave

The following code in VirtRegMap.cpp is asserting in the C++ library because back() is called on an empty container: /// addLastUse - Add the last use information of all stack slots whose /// values are available in the specific register. void addLastUse(unsigned PhysReg, MachineInstr *Use) { std::multimap<unsigned,...

Thanks Lang! Here's another question: I'm trying to process this input: int main() { return 0; } but I'm getting an error Assertion `!Fn.getRegInfo().getNumVirtRegs() && "Regalloc must assign all vregs"' failed. At the start of runOnMachineFunction I call Fn.getRegInfo().getNumVirtRegs(); and find that there is 1 virtual register. However,

...rvals created (%reg1631) gets mark as > rematerializable by > LiveIntervals: > > 00984 if (CreatedNewVReg) { > 00985 if (DefIsReMat) { > 00986 vrm.setVirtIsReMaterialized(NewVReg, ReMatDefMI/*, > CanDelete*/); > 00987 if (ReMatIds[VNI->id] == VirtRegMap::MAX_STACK_SLOT) { > 00988 // Each valnum may have its own remat id. > 00989 ReMatIds[VNI->id] = vrm.assignVirtReMatId(NewVReg); > > Linear scan dutifully assigns %reg1631 to AL. Then SimpleSpiller > runs and > does this: > > 00261 unsig...

...ps *every* vreg, and the other only maps those > for which MRI->reg_empty(vreg) returns false. In both cases I get a core > dump somewhere after my reg-allocation pass has run (when I use the "tst.c" > file that I sent last time as input). > > Note also that there is no VirtRegMap.h in the "include" directory of my > installed llvm-3.1. I had to copy that file from the source directory. > That seems suspicious. > > Any thoughts? > > Thanks! > > Susan > > > On 10/31/2012 07:51 PM, Lang Hames wrote: > >> Hi Susan, >>...

...or register assignments on a >> live-range basis. But now I need to rewrite the machine instructions >> and replace all virtual registers by assigned physical registers. I >> see different options for doing it: >> >> a) Normally, I'd use the spiller provided by the VirtRegMap class. But >> currently, it assumes that live register has only one physical >> register assigned to it. > > Right. > >> >> >> b) It could be possible to change LiveIntervalsAnalysis so that it >> creates a new LiveInterval for each live range. But this...

...his before register allocation? >>> Basically, I'm >> >> Codegen can definitely create stack slots during isel lowering. I >> don't think you can assume all non-fixed slots are created during >> register allocation. > > Ok, so isn't there a bug in VirtRegMap::RemoveMachineInstrFromMaps > since > it assumes every stack index is >= LowSpillSlot, which doesn't get > set until > regalloc spill time? > > -Dave > _______________________________________________ > LLVM Developers...

...and the other only maps those for which MRI->reg_empty(vreg) returns > false. In both cases I get a core dump somewhere after my > reg-allocation pass has run (when I use the "tst.c" file that I sent > last time as input). > > Note also that there is no VirtRegMap.h in the "include" directory > of my installed llvm-3.1. I had to copy that file from the source > directory. That seems suspicious. > > Any thoughts? > > Thanks! > > Susan > > > On 10/31/2012 07:51 PM, Lang Hames wrote: > >...