search for: getaliasset

...how X86 handles AL/AX/EAX/ >> RAX all aliasing each other. In the Sparc backend, the only aliases >> are in the FPU, and it doesn't use subregs to model them at this >> point. > > So if AL is a sub-register of EAX (assume this is true even if not), > then will getAliasSet(AL) include EAX, and will getAliasSet(EAX) > include AL? If yes, then I think I'm OK. Yes, I believe so. -Chris

...LiveVariables.cpp to > find out why. Here is the beginning of the BB dump. entry (0x8503c80, LLVM BB @0x8501af0, ID#0): Live Ins: %R0 %R1 %reg1024 = ORI %R0<kill>, 0 %reg1025 = ORI %R1<kill>, 0 V4R0 is getting killed because handleLiveInRegister() is called on all results of getAliasSet() for each of the liveins (this is in LiveIntervals::computeIntervals() ). handleRegisterDef() does a similar thing where calls handlePhysicalRegisterDef() on all members of getAliasSet() returned for the def, which also triggers this problem. Is it calling handle*() on the alias set of a r...

...; > Here is the beginning of the BB dump. > > entry (0x8503c80, LLVM BB @0x8501af0, ID#0): > Live Ins: %R0 %R1 > %reg1024 = ORI %R0<kill>, 0 > %reg1025 = ORI %R1<kill>, 0 > > V4R0 is getting killed because handleLiveInRegister() is called on > all results of getAliasSet() for each of the liveins (this is in > LiveIntervals::computeIntervals() ). > > handleRegisterDef() does a similar thing where calls > handlePhysicalRegisterDef() on all members of getAliasSet() returned > for the def, which also triggers this problem. > > Is it calling handle...

Hi Susan, > You may find the PBQP allocator implementation useful as a reference > to what's involved in adding a new allocator to LLVM. It's located in > lib/CodeGen/RegAllocPBQP.cpp, with supporting files in the lib/CodeGen/ > PBQP directory. > Yes - as far as working allocators go PBQP is pretty simple. If you're just interested in LLVM API details you can focus on

...all defs and uses of the specified interval. void LiveIntervals::spillPhysRegAroundRegDefsUses(const LiveInterval &li, unsigned PhysReg, VirtRegMap &vrm) { unsigned SpillReg = getRepresentativeReg(PhysReg); for (const unsigned *AS = tri_->getAliasSet(PhysReg); *AS; ++AS) // If there are registers which alias PhysReg, but which are not a // sub-register of the chosen representative super register. Assert // since we can't handle it yet. assert(*AS == SpillReg || !allocatableRegs_[*AS] || tri_->isSuperRegister(*A...

On Mar 25, 2007, at 7:12 AM, Christopher Lamb wrote: > While beginning to add vector registers to a back end I came across > the following problem: as soon as I define two sets of registers > that have a many-to-one mapping the live interval pass appears to > double-kill the mapped-onto register. I have the following excerpts > from my RegisterInfo.td. > > def V4R0

...loc_order_end() will give a list of the possible physical registers. When a virtual register is assigned a physical register by v-reg map, that physical register should be in the target register class of the v-reg, and the aliases to that physical register can be found by llvm::TargetRegisterInfo::getAliasSet( physical-register ) The main classes to look at for register information is TargetRegisterClass TargetRegisterInfo MachineRegisterInfo Thanks, Jeff Kunkel On Fri, Jan 28, 2011 at 10:39 AM, John Criswell <criswell at illinois.edu>wrote: > On 1/28/11 8:14 AM, Qingan Li wrote: > >...

While beginning to add vector registers to a back end I came across the following problem: as soon as I define two sets of registers that have a many-to-one mapping the live interval pass appears to double- kill the mapped-onto register. I have the following excerpts from my RegisterInfo.td. def V4R0 : R4v<0 , "V4R0 ", []>, DwarfRegNum<0>; def R0 : Rg<0 ,

I am going to remove these functions from MCRegisterInfo: getSubRegisters() getSuperRegisters() getOverlaps() getAliasSet() They have been replaced with iterator classes, also defined in MCRegisterInfo.h: MCSubRegIterator MCSuperRegIterator MCRegAliasIterator The tree has lots of examples of how to use all three. /jakob

...s the registers which may reside in the same space as the register? In other words the register is either a super or sub register which holds the same physical location in the register set? Could someone please explain what the Alias set is if it is not what I described above? TargetRegisterInfo::getAliasSet( unsigned reg ) Thanks Jeff Kunkel On Thu, Sep 2, 2010 at 1:56 PM, Jeff Kunkel <jdkunk3 at gmail.com> wrote: > I need to model my registers for my allocator. I need to identify the > super-register and the sub-register conflicts. Something like: > > For each set of registers R...

I need to model my registers for my allocator. I need to identify the super-register and the sub-register conflicts. Something like: For each set of registers R in the set of aligned registers defined by the input request virtual register alpha. Now each register block r in R can have zero, one, or more registers defined in the block started at the aligned size and ending at the aligned size plus

On 1/28/11 8:14 AM, Qingan Li wrote: > Thanks for your help with me about the way to access type and size of > Value. > But, I want also know the interface for me to access the type or size > of virtual registers in the SSA form. > 1. I find no way to associate the virtual registers with the Value class. In the in-memory LLVM IR, all of the SSA values are C++ objects derived

Thanks for your help with me about the way to access type and size of Value. But, I want also know the interface for me to access the type or size of virtual registers in the SSA form. 1. I find no way to associate the virtual registers with the Value class. 2. I also tried to get the size of register nReg by: TargetRegisterClass::getSize(), where the TargetRegisterClass object is obtained by