search for: gprpair

Hi, I am experimenting with creating instructions that write into virtual registers that use the ARM GPRPair register class in Pre-RA phase. During register allocation, I hit an assertion because the code is not in SSA form: lib/CodeGen/MachineRegisterInfo.cpp:271: llvm::MachineInstr* llvm::MachineRegisterInfo::getVRegDef(unsigned int) const: Assertion `(I.atEnd() || llvm::next(I) == def_end()) &a...

...00%) BB#21(0x40000000 / 0x80000000 = 50.00%) …… BB#21: derived from LLVM BB %if.end Live Ins: %LR %R2 %R3 %R4 %R5 %R7 %R12 Predecessors according to CFG: BB#6 BB#20 BB#9 BB#14 INLINEASM <es:ldaexd $0, ${0:H}, [$1];> [sideeffect] [mayload] [maystore] [attdialect], $0:[regdef-ec:GPRPair], %R8_R9<earlyclobber,def>, $1:[reguse:GPR], %R4, <!3> %R0<def> = ANDri %R7, 1, pred:14, pred:%noreg, opt:%CPSR<def> %R0<def> = MOVr %LR, pred:1, pred:%CPSR<kill>, opt:%noreg %R1<def> = EORrr %R0, %LR, pred:14, pred:%noreg, opt:%nore...

...def newGPR : RegisterClass<"ARM", [i32], 32, (add (sequence "R%u", 0, 12))>; I can add this new RegisterClass myself and then modify the pseudo-instruction definition to simply use my new RegisterClass. However, TableGen creates a set of dynamically created classes for GPRPairs that hold all the various incarnations of GPRPair sets that correspond to various RegisterClass definitions (like GPR pairs just for R0-R7, another for rGPR that doesn't contain the SP, .). If I add a new RegisterClass however, the dynamically created GPRPair class corresponding to this n...

...; > 32-bit GPR registers to a 64-bit accumulator register. If spilling > > to multiple registers is unsupported, perhaps I can I define a new > > register class consisting of paired GPR registers and pseudo copy > > instructions? > > Yes, that would work. Look at the ARM GPRPair register class. In the PPC case, for CR spilling, the CRs are only really 4 bits; I'd need to define 8-tuples just to pair with 32-bit GPR registers. Under normal circumstances, i32 is the smallest legal type. Instead, to make this work, would I define a 4-bit subregister of the GPRs to hold t...

...registers to a 64-bit accumulator register. If spilling >>> to multiple registers is unsupported, perhaps I can I define a new >>> register class consisting of paired GPR registers and pseudo copy >>> instructions? >> >> Yes, that would work. Look at the ARM GPRPair register class. > > In the PPC case, for CR spilling, the CRs are only really 4 bits; I'd need to define 8-tuples just to pair with 32-bit GPR registers. Under normal circumstances, i32 is the smallest legal type. Instead, to make this work, would I define a 4-bit subregister of the GPRs...

...So you will need two instructions to copy two 32-bit GPR registers to a 64-bit accumulator register. If spilling to multiple registers is unsupported, perhaps I can I define a new register class consisting of paired GPR registers and pseudo copy instructions? Yes, that would work. Look at the ARM GPRPair register class. You don't need pseudo copy instructions, TII::copyPhysReg() is allowed to insert multiple instructions. > > Also, should RA avoid splitting live intervals of accumulators, which creates copy instructions? > > The alternative to live range splitting is spilling, wh...

On Mon, Mar 25, 2013 at 4:02 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Mar 25, 2013, at 2:51 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > > > Yes, it sounds like it will solve the problem. > > > > Using the following example where live ranges of accumulators $vreg_acc0 > and $vreg_acc1 conflict, > > > > MULT

...can model some quite complicated register banks now, and we even use registers to model some encoding constraints. For example, a few ARM instructions like strexd have two register operands that must be an aligned pair of consecutive GPR registers (like r0, r1). This constraint is modeled with the GPRPair register class containing R0_R1, R2_R3, ... pseudo-registers. Sometimes ISAs also assign assembly names to such pseudo-registers, again from ARM: SPR: (s0, s1, ...) 32-bit floating point registers. DPR: (d0, d1, ...) Even-odd pairs of consecutive S-registers. QPR: (q0, q1, ...) Even-odd pairs of...

...rexd/strexd in ARM mode) require - // (even/even+1) GPRs and use %n and %Hn to refer to the individual regs - // respectively. Since there is no constraint to explicitly specify a - // reg pair, we search %H operand inside the asm string. If it is found, the - // transformation below enforces a GPRPair reg class for "%r" for 64-bit data. - if (AsmString.find(":H}") == StringRef::npos) - return NULL; - DebugLoc dl = N->getDebugLoc(); SDValue Glue = N->getOperand(NumOps-1); -- Måns Rullgård mans at mansr.com

...ccumulator register. If spilling > >>> to multiple registers is unsupported, perhaps I can I define a new > >>> register class consisting of paired GPR registers and pseudo copy > >>> instructions? > >> > >> Yes, that would work. Look at the ARM GPRPair register class. > > > > In the PPC case, for CR spilling, the CRs are only really 4 bits; I'd > need to define 8-tuples just to pair with 32-bit GPR registers. Under > normal circumstances, i32 is the smallest legal type. Instead, to make this > work, would I define a 4-bit...

> > I'm not quite convinced by this. On AArch64, GCC supports the %H, %Q > > and %R operand modifiers which very explicitly deal with a pair of > > 64-bit registers. These are intended to be used with the 'r' > > constraint (I asked, specifically because there wasn't a corresponding > > "register-pair" constraint). > > > Admittedly

...rexd/strexd in ARM mode) require - // (even/even+1) GPRs and use %n and %Hn to refer to the individual regs - // respectively. Since there is no constraint to explicitly specify a - // reg pair, we search %H operand inside the asm string. If it is found, the - // transformation below enforces a GPRPair reg class for "%r" for 64-bit data. - if (AsmString.find(":H}") == StringRef::npos) - return NULL; - DebugLoc dl = N->getDebugLoc(); SDValue Glue = N->getOperand(NumOps-1); -- Måns Rullgård mans at mansr.com

...some quite complicated register banks now, and we even use registers to model some encoding constraints. > > For example, a few ARM instructions like strexd have two register operands that must be an aligned pair of consecutive GPR registers (like r0, r1). This constraint is modeled with the GPRPair register class containing R0_R1, R2_R3, ... pseudo-registers. > > Sometimes ISAs also assign assembly names to such pseudo-registers, again from ARM: > > SPR: (s0, s1, ...) 32-bit floating point registers. > DPR: (d0, d1, ...) Even-odd pairs of consecutive S-registers. > QPR: (q...

On Thu, Nov 22, 2012 at 1:19 PM, Tim Northover <t.p.northover at gmail.com> wrote: >> "r" is supposed to be a single register, not a register pair; the fact >> that gcc accepts this is probably an accident. clang should reject >> this code (without crashing, of course). > > I'm not quite convinced by this. On AArch64, GCC supports the %H, %Q > and %R

...> spilling > >>> to multiple registers is unsupported, perhaps I can I define a > >>> new > >>> register class consisting of paired GPR registers and pseudo copy > >>> instructions? > >> > >> Yes, that would work. Look at the ARM GPRPair register class. > > > > In the PPC case, for CR spilling, the CRs are only really 4 bits; > > I'd need to define 8-tuples just to pair with 32-bit GPR > > registers. Under normal circumstances, i32 is the smallest legal > > type. Instead, to make this work, would...

...even v64i1. On the ARM target, for example, these types would be legal: All 8-bit types via ldrb/strb to GPR. (i8, v1i8, v2i4, v4i2, v8i1) All 16-bit types via ldrh/strh to GPR. (i16, f16, v1i16, v2i8, ...) All 32-bit types via ldr/str to GPR and vldr/vstr to SPR. All 64-bit types via ldrd/strd to GPRPair and vldr/vstr to DPR. All 128-bit types via vld1/vst1 to DPair. All 192-bit types via vld1/vst1 to DTriple. All 256-bit types via vld1/vst1 to DQuad. This larger set of legal types also makes it easier to handle things like extractelement <8 x i8> which currently produces an illegal type and...