search for: isallocat

...> %CTR8 > clang: /llvm-trunk/lib/CodeGen/LiveIntervalAnalysis.cpp:446: > void llvm::LiveInterval > s::handlePhysicalRegisterDef(llvm::MachineBasicBlock*, > llvm::MachineBasicBlock::iterator, llvm::SlotIndex, > llvm::MachineOperand&, llvm::LiveInt erval&): Assertion > `!isAllocatable(interval.reg) && "Physregs shouldn't be live out!"' > failed. When machine code is still in SSA form, there are restrictions on what can be done with physical registers, which by their nature can't be in SSA form. Lang and I have been trying to come up with so...

...rts with: register: %CTR8 clang: /llvm-trunk/lib/CodeGen/LiveIntervalAnalysis.cpp:446: void llvm::LiveInterval s::handlePhysicalRegisterDef(llvm::MachineBasicBlock*, llvm::MachineBasicBlock::iterator, llvm::SlotIndex, llvm::MachineOperand&, llvm::LiveInt erval&): Assertion `!isAllocatable(interval.reg) && "Physregs shouldn't be live out!"' failed. in this case the loop is quite simple: 944B BB#8: derived from LLVM BB %for.inc6, ADDRESS TAKEN Live Ins: %CTR8 Predecessors according to CFG: BB#8 BB#3 960B BDNZ8 <BB...

...y for different sub-targets, and even different functions. The reserved registers for a function are computed by the TRI::getReservedRegs(MF) hook. A register is allocatable if it belongs to at least one allocatable register class AND it is not reserved. See RegisterClassInfo.h, in particular the isAllocatable() function. The third set of unallocatable, unreserved registers usually only contains the flags. It is different from the reserved registers because the register allocator is still tracking liveness of these registers. The reserved registers are mostly ignored for liveness tracking. /jakob...

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

...enuine instructions of my target architecture, they use the SR along with operands to produce a result. As you can see ‘t30’ is used both before and after the function call, which is what I think that causes trouble. In particular, the assertion that I get is this: Assertion failed: (RegClass->isAllocatable() && "Virtual register RegClass must be allocatable."), function createVirtualRegister, file /Users/joan/LLVM+CLANG/llvm-7.0.1.src/lib/CodeGen/MachineRegisterInfo.cpp, line 170. If I remove the ‘isAllocatable=0’ setting on the SR register, then LLVM will try to spill the SR b...

...llvm-trunk/lib/CodeGen/LiveIntervalAnalysis.cpp:446: > > void llvm::LiveInterval > > s::handlePhysicalRegisterDef(llvm::MachineBasicBlock*, > > llvm::MachineBasicBlock::iterator, llvm::SlotIndex, > > llvm::MachineOperand&, llvm::LiveInt erval&): Assertion > > `!isAllocatable(interval.reg) && "Physregs shouldn't be live out!"' > > failed. FYI: I just committed the relevant code (disabled by default); and I submitted a bug to track this issue: http://llvm.org/bugs/show_bug.cgi?id=13057 (It seems that I was doing this as you were respo...

On Tue, Feb 2, 2016 at 8:42 PM, Matt Arsenault <arsenm2 at gmail.com> wrote: > > On Feb 2, 2016, at 16:52, Rail Shafigulin <rail at esenciatech.com> wrote: > > def SDT_EscalaSetFlag : SDTypeProfile<0, 3, [SDTCisSameAs<0, 1>]>; > > > I think for setting an implicit register, you still need to have 1 result > here. > > If you look at

...my target architecture, they use the SR along with operands to produce a result. > > As you can see ‘t30’ is used both before and after the function call, which is what I think that causes trouble. In particular, the assertion that I get is this: > > Assertion failed: (RegClass->isAllocatable() && "Virtual register RegClass must be allocatable."), function createVirtualRegister, file /Users/joan/LLVM+CLANG/llvm-7.0.1.src/lib/CodeGen/MachineRegisterInfo.cpp, line 170. > > If I remove the ‘isAllocatable=0’ setting on the SR register, then LLVM will try to spi...

In the definition of register classes, have you provided any value types for each class? -Krzysztof On 1/9/2019 7:19 PM, m m via llvm-dev wrote: > The file that is causing this assertion contains only 3 include statements > > |//===-- ABCOther.td - Describe the ABC Target Machine ----*- tablegen > -*-===// // // >

...nstruction that uses it, you want to model this dependency with an unallocatable physical register, e.g. the CPSR on ARM: // Condition code registers. def CCR : RegisterClass<"ARM", [i32], 32, (add CPSR)> { let CopyCost = -1; // Don't allow copying of status registers. let isAllocatable = 0; } This will require you to mark defs and uses (and kills), but if you're using it purely inside of a single basic block you won't have to worry about it too much. If you have instructions that may only generate this dependency in certain circumstances, you can use implicit def/use...

...uery pressure for a specific set... P = RPTracker.getPressureAfterInst(I) diff = P[PsetID] - RPTracker.getRegSetPressureAtPos()[PSetID] Note that how you define your target’s registers can make a big difference in the pressure set formation. Yours don’t look to bad, but in general remember to use isAllocatable=0 for any classes that don’t take part in regalloc. -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130722/2f9cf2ff/attachment.html>

Hi, I'm working on defining a SchedMachineModel for the Southern Islands family of GPUs, and I have two questions related to the MachineScheduler. 1. I have a resource that can process 15 instructions at the same time. In the TableGen definitions, should I do: def HWVMEM : ProcResource<15>; or let BufferSize = 15 in { def HWVMEM : ProcResource<1>; } 2. Southern Islands has

I am using some non-allocatable RegisterClasses to define lists of registers that are used for various non-allocation-related processing in the back end. For example, we have a post-allocation functional unit selection pass that is guided by the register assignment, which does things like 'myRegClass.contains(Reg)' to see if a register is in the set of registers accessible by a given unit.

On Fri, 08 Jun 2012 09:24:16 -0700 Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jun 8, 2012, at 9:02 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > On Fri, 8 Jun 2012 08:49:32 -0700 > > Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > >> When machine code is still in SSA form, there are restrictions on > >> what can

...ou want to model this dependency with an unallocatable physical register, e.g. the CPSR on ARM: > > // Condition code registers. > def CCR : RegisterClass<"ARM", [i32], 32, (add CPSR)> { > let CopyCost = -1; // Don't allow copying of status registers. > let isAllocatable = 0; > } > > This will require you to mark defs and uses (and kills), but if you're using it purely inside of a single basic block you won't have to worry about it too much. If you have instructions that may only generate this dependency in certain circumstances, you can use im...

I attempt to optimize the use of the ‘CMP’ instruction on my architecture by removing the instruction instances where the Status Register already had the correct status flags. The cmp instruction in my architecture is the typical one that compares two registers, or a register with an immediate, and sets the Status Flags accordingly. I implemented my ‘cmp’ instruction in LLVM by custom lowering

...ciate if you could point out where in the code this is happening. I've also followed your advice and added i1 as a type for my SPR def SPR : RegisterClass<"Esencia", [i1,i32], 32, (add SR)> { let CopyCost = -1; // Don't allow copying of special purpose registers. let isAllocatable = 0; } Then I changed an instruction class to return an explicit value class SF_RR<bits<5> op2Val, string asmstr, PatLeaf Cond> : InstRR<0x9, (outs), (ins GPR:$rA, GPR:$rB), !strconcat(asmstr, "\t$rA, $rB"), [(set SPR:$rC, (Esencia...

It does have an output register, it's just an implicit flag register. It still has a DAG output. I'm not sure if the allocatable bit matters at this point for selection purposes, but it does later. Not adding a type to the register class can also be problematic (e.g. a flag register should have i1 added to regTypes for its class). -Matt > Does LLVM make an assumption that there is an

...> I already had 2 register classes before and everything was working. All > I've done is that I had added an extra class. After that LLVM started to > complain. And this is what puzzles me. > > Did you add a register class for a special condition register? Did you set > it as isAllocatable = 0? > I think I'm slowly getting it. To answer your question, no I did not set isAllocaable = 0 for the new register class. But I'm still confused. Original instruction does not have an output register. It sets a flag in the special purpose register. So why creating a new register...

On Jun 7, 2012, at 7:31 PM, Hal Finkel wrote: > 112B BB#1: derived from LLVM BB %for.body, ADDRESS TAKEN > Predecessors according to CFG: BB#0 BB#1 > %vreg12<def> = PHI %vreg13, <BB#1>, %vreg11, <BB#0>;CTRRC8:%vreg12,%vreg13,%vreg11 > %vreg13<def> = COPY %vreg12<kill>; CTRRC8:%vreg13,%vreg12 > %vreg13<def> = BDNZ8 %vreg13,