search for: regunits

...d register unit? I'm seeing a LiveInterval with li->reg == 0 show up, which previously wasn't valid. We have a few checks around the place to disregard the '0' physreg - could these trigger on interaction with a '0' interval? That could introduce some subtle bugs. Right. Regunits are numbered independently from physregs, starting from 0. Each regunit corresponds to one or two physregs, the 'roots', which are typically leaf registers. The mapping is exposed by MCRegUnitIterator and MCRegUnitRootIterator. Regunit live intervals are more strictly defined than the old...

Hi Jakob, I've got a good test case that I'm working on at the moment. I noticed something odd though: Is '0' a valid register unit? I'm seeing a LiveInterval with li->reg == 0 show up, which previously wasn't valid. We have a few checks around the place to disregard the '0' physreg - could these trigger on interaction with a '0' interval? That could

Ok, just to clarify, RegUnits, as far I understand, are Physical registers or alias to Physical registers. They exist because some instructions use physical registers directly rather than virtual register. It's right? And why this RegUnits should be present in the Interference Graph? I thought were only the Live Intervals...

...no "most super" register? I'm having a hard time thinking up how one would design such an ISA. Need to increase my edjimucation. > We try to track anything related to register aliasing in terms of > register units. See MCRegisterInfo.h and TargetRegisterInfo.h. I > believe regunits are equivalent to maximal cliques of the register > aliasing graph if you're mathematically inclined. Ok, I'll check that out. MCRegisterInfo.h is new to me. > I think it is easier to think about them as minimal sub-registers, > even if that is not always completely accurate. I...

...Here, Q0 is the name we use for D0_D1 (which doesn't exist). This register structure also means that the complete set of aliasing registers can get quite large. Some NEON registers have more than 40 aliases. The register units help control that complexity. Each physreg has an associated set of regunits, and two physregs alias if and only if their regunit sets overlap. See TRI::regsOverlap(). The regunits usually correspond to the leaf sub-registers - the registers that have no sub-registers themselves. However, the numbering is different, and if you use 'Aliases = ...' in your register f...

Good Night. I'm implementing a Interference Graph in the Register Allocation pass. I'm building this graph BEFORE any assignment of a virtual register to physical register. But I have a doubt about how to check the interference between two Live Intervals (i.e. They live at same point), should I use: L1->overlaps(L2) Where L1 and L2 are two different Live Intervals. Or should I use:

On 9/28/2016 1:20 PM, Quentin Colombet wrote: > >> On Sep 28, 2016, at 10:52 AM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On X86, the registers AX, EAX and RAX all share the exact same register units. In terms of units, there is no difference between these registers. This makes register units insufficient to track liveness, since live AX

On X86, the registers AX, EAX and RAX all share the exact same register units. In terms of units, there is no difference between these registers. This makes register units insufficient to track liveness, since live AX does not imply live EAX. Would it make sense to have register units (and lane masks) for the parts of registers that are not individually addressable? -Krzysztof -- Qualcomm

...mpiler? As I can see, there is an implementation of the 'print(raw_ostream &OS, const Module*)' method in the 'LiveIntervals.cpp'. void LiveIntervals::print(raw_ostream &OS, const Module* ) const { OS << "********** INTERVALS **********\n"; // Dump the regunits. ... The method also is implemented in 'RegisterCoalescer.cpp' (in fact, this method just invokes one from LiveIntervals). Is there a way to invoke the 'print' method implemented in **Machine** pass? If so, could you let me know how I can do it? Thank you. Pavel --------------...

...tree. The graph of sub/super-register relationships is also not a tree, it is a DAG. Take a look at the ARM register bank. It demonstrates most of this stuff. We try to track anything related to register aliasing in terms of register units. See MCRegisterInfo.h and TargetRegisterInfo.h. I believe regunits are equivalent to maximal cliques of the register aliasing graph if you're mathematically inclined. I think it is easier to think about them as minimal sub-registers, even if that is not always completely accurate. /jakob

...) will either return the cached live range or compute it from scratch. That won't help. It's calling getCachedRegUnit() here because there is no point in updating live ranges that haven't been computed yet. Sergei, we don't compute live ranges for physical registers any more. Only regunits. /jakob

I'm working on the post-regalloc dataflow engine I mentioned yesterday. Currently I only need to track register operands. A MachineOperand has both a getReg() and a getSubReg() interface. For a physical register operand, is getReg() guaranteed to be the "most super" register with getSubReg() providing the specific subregister information for the operand? If so then for my current

The code in collectRanges() does: // Collect ranges for register units. These live ranges are computed on // demand, so just skip any that haven't been computed yet. if (TargetRegisterInfo::isPhysicalRegister(Reg)) { for (MCRegUnitIterator Units(Reg, &TRI); Units.isValid(); ++Units) if (LiveInterval *LI = LIS.getCachedRegUnit(*Units))

On 9/28/2016 7:30 PM, Quentin Colombet wrote: > Out of curiosity, could describe why this is useful to have such precision in the liveness tracking? RDF is meant to allow optimizations across the whole function. As a result, registers may change between basic blocks, and there is code to recalculate it. Accuracy is required to avoid unnecessary block live-ins. For example, calculate live-ins

...use of MCRegAliasIterator because some of the alias lists are so long. In most cases, it should be possible to express algorithms in terms of register units instead. I also want to avoid emitting tables for driving MCRegAliasIterator. If required, the set of aliasing registers can be computed from regunits and super-registers. (See the block comment for MCRegUnitRootIterator or LiveIntervals::computeRegUnitInterval). /jakob

Hi, I have a problem with the assert in Tablegen: llvm-tblgen: /dev/shm/uabpath/dev-master/utils/TableGen/RegisterInfoEmitter.cpp:204: void <anonymous namespace>::RegisterInfoEmitter::EmitRegUnitPressure(llvm::raw_ostream &, const llvm::CodeGenRegBank &, const std::string &): Assertion `RU.Weight < 256 && "RegUnit too heavy"' failed. The reason for

To: Andrew Trick Hi, I write you directly as you are the commiter of the code I am having problems with for my target - see below. I wonder what you think about this? Thanks, Jonas ________________________________ From: Jonas Paulsson Sent: Thursday, December 06, 2012 4:14 PM To: llvmdev at cs.uiuc.edu Subject: Register classes, reg unit weights calculation in tablegen Hi, I have a problem

Hi there, In my register allocator, I was trying to get the parent of a register in ARM. That is: D0 <-> S0, S1. Given S0, how am I able to get D0? Thanks, Xiaochu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160719/3cc73e78/attachment.html>

...egAliasIterator because some of the alias lists are so long. In most cases, it should be possible to express algorithms in terms of register units instead. > > I also want to avoid emitting tables for driving MCRegAliasIterator. If required, the set of aliasing registers can be computed from regunits and super-registers. (See the block comment for MCRegUnitRootIterator or LiveIntervals::computeRegUnitInterval). > > /jakob > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lis...

Hi I'm returning to my MC6809 back-end from a health-related hiatus. The assembler is tantalisingly close, but I've got some parsing and matching problems. The register set; these overlap in annoying ways, for instance, two instructions TFR and EXG each have a single opcode, and the post-byte specifies which registers are to be involved, but the registers can be 8- or 16-bit, and 2 of