search for: getallocatableset

On Apr 29, 2010, at 2:06 PM, Villmow, Micah wrote: > Ping. Anyone have any idea on how to fix this? Does your getAllocatableSet() return a BitVector that is at least getNumRegs() bits long? Otherwise this doesn't work: BitVector NonAllocatableRegs = TRI->getAllocatableSet(MF); NonAllocatableRegs.flip();

Jakob, Here is my implementation of getAllocatableSet: BitVector AMDILRegisterInfo::getAllocatableSet(const MachineFunction& MF, const TargetRegisterClass *RC = NULL) const { BitVector Allocatable(getNumRegs()); Allocatable.clear(); return Allocatable; } Micah -----Original Message----- From: Jakob Stoklund Olesen [mailto:stoklund at 2pi....

...InstructionElim pass enabled, which is causing havoc with my backend. Before entering this pass, everything in my machine function is fine, after this pass, all instructions that are not function calls are deleted. I've tracked this issue down to the line: BitVector NonAllocatableRegs = TRI->getAllocatableSet(MF); (In my case all registers defined in RegisterInfo.td) This function loops through all registers classes and sets all registers in the bitset that are allocatable. It then inverts the registers that are set to get the NonAllocatable registers and assigns that to the LivePhysRegs for each basic...

...InstructionElim pass enabled, which is causing havoc with my backend. Before entering this pass, everything in my machine function is fine, after this pass, all instructions that are not function calls are deleted. I've tracked this issue down to the line: BitVector NonAllocatableRegs = TRI->getAllocatableSet(MF); (In my case all registers defined in RegisterInfo.td) This function loops through all registers classes and sets all registers in the bitset that are allocatable. It then inverts the registers that are set to get the NonAllocatable registers and assigns that to the LivePhysRegs for each basic...

...InstructionElim pass enabled, which is causing havoc with my backend. Before entering this pass, everything in my machine function is fine, after this pass, all instructions that are not function calls are deleted. I've tracked this issue down to the line: BitVector NonAllocatableRegs = TRI->getAllocatableSet(MF); (In my case all registers defined in RegisterInfo.td) This function loops through all registers classes and sets all registers in the bitset that are allocatable. It then inverts the registers that are set to get the NonAllocatable registers and assigns that to the LivePhysRegs for each basic...

...ch register class are initialised for the function, i.e. the lines: for (TargetRegisterInfo::regclass_iterator I = tri_->regclass_begin(), E = tri_->regclass_end(); I != E; ++I) allocatableRCRegs_.insert(std::make_pair(*I, tri_->getAllocatableSet(fn, *I))); If the allocatable registers are dependent on the function, such as might occur when a frame pointer isn't required, then it seems that every function will use the same allocatable set as the first function. [ a DenseMap insert operation has no effect if the key is already present ]...

...initialised for the function, i.e. the lines: > > for (TargetRegisterInfo::regclass_iterator I = tri_->regclass_begin(), > E = tri_->regclass_end(); I != E; ++I) > allocatableRCRegs_.insert(std::make_pair(*I, > tri_->getAllocatableSet(fn, *I))); > > If the allocatable registers are dependent on the function, such as might occur when a frame pointer isn't required, then it seems that every function will use the same allocatable set as the first function. [ a DenseMap insert operation has no effect if the key is already...

...& allocatableRegs_[Reg] && RC->contains(Reg)) mri_->setRegAllocationHint(cur->reg, 0, Reg); where "allocatableRegs_" is calculated during pass init, and ignores register class. I think this should be changed to: if (Reg && (tri_->getAllocatableSet(*mf_, RC))[Reg] && RC- >contains(Reg)) mri_->setRegAllocationHint(cur->reg, 0, Reg); or, if compilation speed discourages calling "getAllocatableSet" so often, create "allocatableRegs_" array per register-class, instead of just one. If it is...

...tionElim pass enabled, which is causing havoc with my backend. Before entering this pass, everything in my machine function is fine, after this pass, all instructions that are not function calls are deleted. I’ve tracked this issue down to the line: > > BitVector NonAllocatableRegs = TRI->getAllocatableSet(MF); (In my case all registers defined in RegisterInfo.td) > > This function loops through all registers classes and sets all registers in the bitset that are allocatable. It then inverts the registers that are set to get the NonAllocatable registers and assigns that to the LivePhysRegs for...

...the function, i.e. the lines: >> >> for (TargetRegisterInfo::regclass_iterator I = tri_->regclass_begin(), >> E = tri_->regclass_end(); I != E; ++I) >> allocatableRCRegs_.insert(std::make_pair(*I, >> tri_->getAllocatableSet(fn, *I))); >> >> If the allocatable registers are dependent on the function, such as might occur when a frame pointer isn't required, then it seems that every function will use the same allocatable set as the first function. [ a DenseMap insert operation has no effect if the key is...

Dear LLVM guys, I am coding a liveness analysis algorithm, and I found this comment on LiveVariables.cpp: Line 00195 - http://llvm.org/doxygen/LiveVariables_8cpp-source.html : // PhysRegInfo - Keep track of which instruction was the last use of a // physical register. This is a purely local property, because all physical // register references as presumed dead across basic blocks.

...just opaque text. Now we can warn users if they're using it wrong, or if there's any danger of clobbering the wrong registers, because we have that knowledge in the MC layer. Makes sense? > - We don't have a generic register reservation mechanism today. Well, TargetRegisterInfo::getAllocatableSet() enquires the targets for getReservedRegs() which could be set to take into account named register globals. Since they're module globals, this could be done once per compilation job, making it a lot simpler. > If you don't believe the last part... I didn't say it would be simple....

On 28 March 2014 10:17, Chandler Carruth <chandlerc at google.com> wrote: > This has been the long standing historical objection to the feature. It is a > *really* invasive change to the register allocator to plumb this kind of > register reservation through it. Do you mean only the reserved part or the general named register idea? About reserving registers, we already have the

...SelectionDAG.a(InstrEmitter.cpp.o) "typeinfo for llvm::TargetSubtarget", referenced from: typeinfo for llvm::EBCSubtargetin libLLVMEBCCodeGen.a(EBCTargetMachine.cpp.o) typeinfo for llvm::EBCSubtargetin libLLVMEBCCodeGen.a(EBCSubtarget.cpp.o) "llvm::TargetRegisterInfo::getAllocatableSet(llvm::MachineFunction const&, llvm::TargetRegisterClass const*) const", referenced from: llvm::TargetInstrInfo::isReallyTriviallyReMaterializableGeneric(llvm::MachineInstr const*, llvm::AliasAnalysis*) constin libLLVMCodeGen.a(TargetInstrInfoImpl.cpp.o) (anonymous namespace)::Machin...