search for: tri_

...rate incorrect code for any of the supported targets. I believe that there may be a problem in SimpleRegisterCoalescing::runOnMachineFunction where the allocatable registers for each 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...

...for any of the supported targets. > > I believe that there may be a problem in SimpleRegisterCoalescing::runOnMachineFunction where the allocatable registers for each 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 mig...

.../ 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 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_->is...

...supported targets. >> >> I believe that there may be a problem in SimpleRegisterCoalescing::runOnMachineFunction where the allocatable registers for each 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 func...

...citly select another target for cross-compilation by doing > > --march=sparc or --march=alpha. > > I did the once-per-module solution to this exact problem. Here's what it > looks like: > > class RA { > const TargetMachine* tm_; > const TargetRegisterInfo* tri_; > const TargetInstrInfo * tii_; > [...] > bool RA::runOnMachineFunction(MachineFunction &fn) { > mf_ = &fn; > tm_ = &fn.getTarget(); > tri_ = tm_->getRegisterInfo(); > tii_ = tm_->getInstrInfo(); > > if (!initialized) { > build_cla...

...t; %reg1026: [458,5168:0 [0]) > %reg15: [938,942:1 [0]) > > My assumption was that after MergeInClobberRanges that %reg15 > would contain [458,5168:0 [0]). But it doesn't. So this is the call site? // Update the liveintervals of sub-registers. for (const unsigned *AS = tri_->getSubRegisters(DstReg); *AS; ++AS) li_->getOrCreateInterval(*AS).MergeInClobberRanges(*ResSrcInt, li_- >getVNInfoAllocator()); Can you take a look at MergeInClobberRanges() to see what is going on? Otherwise, please file a bug...

Hi, I'm playing with some experimental register allocators for LLVM. One of them needs to build a so-called register class tree for representing the aliasing information among register classes. This tree is not function or module specific. It is actually target specific, because it depends only on the register classes defined for a machine that is used as a target of the current compilation.

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

...s is ok as-is. Just curious. > > My assumption was that after MergeInClobberRanges that %reg15 > > would contain [458,5168:0 [0]). But it doesn't. > > So this is the call site? > > // Update the liveintervals of sub-registers. > for (const unsigned *AS = tri_->getSubRegisters(DstReg); *AS; ++AS) > li_->getOrCreateInterval(*AS).MergeInClobberRanges(*ResSrcInt, > li_- Yep. > >getVNInfoAllocator()); > > Can you take a look at MergeInClobberRanges() to see what is going on?...

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

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