similar to: [LLVMdev] Possible bug in SimpleRegisterCoalescing

On Sep 12, 2011, at 10:56 AM, Steve Montgomery wrote: > While working on a back-end for a target, I've come across something I believe to be a bug in SimpleRegisterCoalescing.cpp. I'm unsure how / whether to report it because I don't think it will necessarily crash or generate incorrect code for any of the supported targets. > > I believe that there may be a problem in

Thanks for your help. I've tried building from the trunk and it works, as you'd suggested. On 13 Sep 2011, at 01:00, Jakob Stoklund Olesen wrote: > > On Sep 12, 2011, at 10:56 AM, Steve Montgomery wrote: > >> While working on a back-end for a target, I've come across something I believe to be a bug in SimpleRegisterCoalescing.cpp. I'm unsure how / whether to

On Feb 20, 2008, at 7:36 PM, David A. Greene wrote: > On Wednesday 20 February 2008 07:00:28 pm Evan Cheng wrote: > >>> In other words, after coalescing, should it be the case that >>> subregister >>> intervals contain at least all of the range information that was >>> contained >>> in any eliminated intervals when those eliminated intervals were

I am hitting this assert in LLVM 2.5: /// spillPhysRegAroundRegDefsUses - Spill the specified physical register /// around all defs and uses of the specified interval. void LiveIntervals::spillPhysRegAroundRegDefsUses(const LiveInterval &li, unsigned PhysReg, VirtRegMap &vrm) { unsigned SpillReg = getRepresentativeReg(PhysReg); for (const

Hi, I'm implementing some variations of graph-coloring register allocators for LLVM. Many of them perform their phases (e.g. coalescing, graph simplification, spilling, color selection) in an iterative way. Since LLVM provides an implementation of the coalescing in the SimpleRegisterCoalescing class already, I would like to reuse it (even though I could of course create my own coalescing

On Friday 09 January 2009 03:36, Roman Levenstein wrote: > Hi, > > I'm implementing some variations of graph-coloring register allocators for > LLVM. Many of them perform their phases (e.g. coalescing, graph > simplification, spilling, color selection) in an iterative way. Since > LLVM provides an implementation of the coalescing in the > SimpleRegisterCoalescing class

Hi, I'm writing to ask the differences between a "reserved" register and an "unallocable" register. In X86 backend, for example, the stack pointer register and instruction pointer are reserved but allocatable. In the Doxygen document of function llvm::TargetRegisterInfo::getReservedRegs, it says that a reserved register is one that *has particular uses and should be

On Wednesday 20 February 2008 07:00:28 pm Evan Cheng wrote: > > In other words, after coalescing, should it be the case that > > subregister > > intervals contain at least all of the range information that was > > contained > > in any eliminated intervals when those eliminated intervals were > > coalesced > > to the subregister's superregister? >

On Apr 17, 2012, at 9:09 PM, Lei Mou wrote: > I'm writing to ask the differences between a "reserved" register and an "unallocable" register. In X86 backend, for example, the stack pointer register and instruction pointer are reserved but allocatable. In the Doxygen document of function llvm::TargetRegisterInfo::getReservedRegs, it says that a reserved register is one

On Feb 20, 2008, at 12:25 PM, David Greene wrote: > On Wednesday 20 February 2008 14:14, David Greene wrote: > >> I discovered this through an assert I put into some of my own >> code. I want >> to know if that assert is bogus or if there's a bug here. > > A little more information: the assert checks that after coalescing > two nodes, > all subregister

Hi, again, I think I got around this problem of discovering the class of a physical register. I am using this code here: void PhiDeconstruction_Fer::add_move (MachineBasicBlock & mbb, unsigned src, unsigned dst) { MachineBasicBlock::iterator iter = mbb.getFirstTerminator(); const MRegisterInfo * reg_info =

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();

> On Sun, 2 Jul 2006, Fernando Magno Quintao Pereira wrote: > > > MachineBasicBlock::iterator iter = mbb.getFirstTerminator(); > > const TargetRegisterClass *rc = mf.getSSARegMap()->getRegClass(dst); > > const MRegisterInfo * reg_info = mf.getTarget().getRegisterInfo(); > > reg_info->copyRegToReg(mbb, iter, dst, src, rc); > > } > > >

Hi people, the LinearScan register allocator tries to use same register for both live intervals, if the new interval is defined by a register copy whose destination reg is compatible with the source register. This is ok. However, this "check for compatibility" is wrongly done IMHO. Say I have regclass1 with reg A, and regclass2 with regs {A, B}, but regclass2 defines only

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.dk] Sent: Monday, May 03, 2010 9:52 AM To:

On Thursday 21 February 2008 01:23, Evan Cheng wrote: > > Also, LiveIntervalAnalysis doesn't do any subregister checks as > > far as I can tell. It's certainly not the case that subregister > > intervals contain all of the information their supperregister's > > interval contains. > > SimpleRegisterCoalescing::JoinIntervals(). When coalescing a physical

Dear guys, I want to coalesce some copies, and I would like to know if there is any method that I can call, like JoinCopy from the old (LLVM 1.9) LiveIntervals class. I found it in SimpleRegisterCoalescing (LLVM 2.1), but I do not want to call this analysis, as I have my own. basically, I can determine that two virtuals do not overlap, and I know that it is safe to join them. In

On Jul 11, 2007, at 11:39 AM, David Greene wrote: > On Wednesday 11 July 2007 12:41, Tanya M. Lattner wrote: > >> I think the coalescer should be flexible enough to be run >> independent of >> the register allocator. For example, you may want to expose the >> copies >> induced by transforming out of SSA to the scheduler. If the >> scheduler is

On Wed, May 25, 2016 at 3:53 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > ------------------------------ > > *From: *"vivek pandya" <vivekvpandya at gmail.com> > *To: *"Quentin Colombet" <qcolombet at apple.com> > *Cc: *"Hal Finkel" <hfinkel at anl.gov>, "llvm-dev" <llvm-dev at lists.llvm.org>, >

Dale, Yeah that is correct, so that isn't the problem, not sure why I was thinking it is. The !MRI->use_no_dbg_empty(Reg) seems to be correct and the problem is LivePhysRegs[Reg] always returning false. I've looked into this more and there is a part where I'm working with physical registers. If there is a function call, there is a copy from virtual register space to the functions