search for: regunit

...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 Interval...

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

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

...hysical 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: L1->overlaps(RG1) Where L1 is a Live Interval and RG1 is a RegUnit for an arbitrary physical register. I saw this second method in the PBQP allocator code, I think that maybe will be related to avoid allocation to reserved physical registers or for a on-the-fly check for interference, but the LiveRegMatrix already do that. So my question is: Considering that I w...

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

...ra.org> wrote: > 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)) > collectRanges(MO, LI, Entering, Internal, Exiting, OldIdx); > } else { > // Collect ranges for individual virtual registers. > colle...

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)) collectRanges(MO, LI, Entering, Internal, Exiting, OldIdx); } else { // Collect ranges for individual virtual registers. collectRanges(MO, &LI...

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 this is that I have constructed pred-operands to be of the register class type FlagRegs, which holds a big...

...4:14 PM To: llvmdev at cs.uiuc.edu Subject: Register classes, reg unit weights calculation in tablegen 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 this is that I have constructed pred-operands to be of the register class type FlagRegs, which holds a big...

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://li...

...elow. I can't make sense of the "too heavy" part. Could one of you kind folks clue me in please? Without the above ALLREG group, the code compiles and while not complete or altogether correct, is testable and somewhat functional. Assertion failed: (RU.Weight < 256 && "RegUnit too heavy"), function EmitRegUnitPressure, file /usr/local/src/llvm/llvm/utils/TableGen/RegisterInfoEmitter.cpp, line 237. 0 llvm-tblgen 0x000000010bc2b66c llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 60 1 llvm-tblgen 0x000000010bc2bc09 PrintStackTraceSignal...