search for: ccreg

...ange code when using regalloc=greedy. A value spill is redundant and cleared, as another spill of same value is inserted. The former spill is however not NOP:ed, but KILL:ed, thus the operands get a kill status. The code becomes: %vreg301<def> = mv32Imm 200000000, pred:0, pred:%noreg, %CCReg<imp-def,dead>, %ac0<imp-use>, %ac1<imp-use>; aN32_0_7:%vreg301 Store32FI %vreg301, <fi#93>, pred:0, pred:%noreg, %CCReg<imp-def>; mem:ST4[FixedStack93] aN32_0_7:%vreg301 KILL %vreg301, <fi#93>, 0, %noreg, %CCReg<imp-def>; mem:ST4[FixedStack93] aN32_...

Hi, I am in the process of porting our target to GlobalISel, and have encountered a problem. Nearly all instructions in our instruction set make modifications to a CC register, and hence are defined as follows: let ..., Defs = [CCReg] in def shfts_a32_imm7: Instruction<(outs OurRC:$dst), ...>; What's more, many of these instructions have patterns where the instruction itself appears inside a nested tree, e.g.: def Pat<(source pattern ...), (sext_a32 (INSERT_SUBREG (...), (shfts_a32_imm7 OurRC:$src,...

...move it from the instruction TableGen gives me a different error message which concerns a part which is deeper into the pattern tree, so at least it is able to proceed beyond that part of the pattern. I have also stepped TableGen inside gdb and verified that having Defs causes GlobalISel to include CCReg in the Types field of the TreePatternNode corresponding to the instruction, which is what GlobalISel looks at to subsequently reject the pattern on basis that the instruction produces multiple results. But from your comment, I take it that the Defs field should never be considered actual output...

...1, TARGET_VAL(OurTarget::sext_a32), 0, MVT::i40, 4/*#Ops*/, 13, 14, 15, 16, ... The line of interest here is the one below /* 70 */. There, we can see that the instruction produces two results of type MVT::i32 (the value produced by the instruction) respectively MVT::i16 (the CCReg updated by the instruction). These are labeled as results #10 respectively #11. Looking at operand identifiers after /*#Ops*/, we can see that only #10 is used by the rest of the resulting pattern (by INSERT_SUBREG), which is as intended. However, in the destination pattern declared in the *.td...

...ot want to produce spill code. In a backend on which I have been working, we have a compare instruction that sets a flag (true or false), and a conditional branch instruction, that jumps if the flag is true. Initially, I tried to specify this by providing a lowering of the compare instruction : (CCReg only contains one register) def CMPEQ : Instr< (outs CCReg:$dst), (ins IntRegs:$lhs, IntRegs:$rhs), "cmpeq $lhs, $src", [(cmpeq IntRegs:$dst, IntRegs:$src)>; def BCC : Instr< (outs), (ins CCReg:$cc, brtarget:$addr), "bcc $addr", [(brcond CCReg:$cc, b...

On Jan 20, 2012, at 6:40 AM, Jonas Paulsson wrote: > > What exactly are you proposing? Why can't you do what the PowerPC and Hexagon targets do? > > Yes, I can move a CR to a GPR and save it to the stack, but due to a very irregular register file this is about 10 times more expensive than saving/restoring an ordinary register. These registers should basically never > have to

> On Jan 19, 2012, at 5:31 AM, Jonas Paulsson wrote: > LLVM would have to be extended with an RegClass/register-attribute 'spillable' > > > What exactly are you proposing? Why can't you do what the PowerPC and Hexagon targets do? Yes, I can move a CR to a GPR and save it to the stack, but due to a very irregular register file this is about 10 times more expensive

...1 ... After register coalescing and until dead-mi-elimination, it looks like this: bb.0: ... undef %5.hiPair_then_loAcc:an32quads = COPY %12 ... bb.1: ... %5.hiPair_then_loAcc:an32quads = or_a40_a40_a40_aN32 %5.hiPair_then_loAcc, %21, 0, $noreg, 0, implicit-def dead $ccreg ... bb.3: ... %5.hiPair_then_hiAcc:an32quads = COPY undef %11 ... Then after dead-mi-elimination, all that remains is: bb.3: ... %5.hiPair_then_hiAcc:an32quads = COPY undef %11 ... This is what's directly involving %5, so I hope it is the right amount of inf...

...must then be considered bad code in LLVM. But if I write %reg16507<def> = COPY %reg16445; %reg16508<def> = COPY %reg16468; %reg16506<def> = REG_SEQUENCE %reg16507, hi16, %reg16508, lo16; %reg16509<def> = st_2_1_postMod %reg16506, %reg16441, %reg16454, pred:20, pred:%CCReg; then, there is not an erroneous live-range that interferes, so it coalesces. I suppose this means that the first version with INSERT_SUBREG's is breaking the SSA-form? Or am I doing it wrong? In a similar case, the coalescer will not join the %reg16478 into %reg16511, although it mak...

...se common sub/super reg-classes. static const RegClassWeight RCWeightTable[] = { {4294967295, 4294967288}, // FlagRegs ... Does anyone have a suggestion of how to get around this problem? It would be a big task to rewrite the instructions to have different types of pred-operands depending of used CCReg, etc. Could perhaps the unit weight calculation be fixed to handle more intricate cases like this? Who could I work with on this in this case? Thanks, Jonas Paulsson -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/atta...

...se common sub/super reg-classes. static const RegClassWeight RCWeightTable[] = { {4294967295, 4294967288}, // FlagRegs ... Does anyone have a suggestion of how to get around this problem? It would be a big task to rewrite the instructions to have different types of pred-operands depending of used CCReg, etc. Could perhaps the unit weight calculation be fixed to handle more intricate cases like this? Who could I work with on this in this case? Thanks, Jonas Paulsson -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/atta...

Hi, After dead-mi-elimination I'm experiencing a machine verifier failure at this virtual subregister write: %5.sub1 = COPY undef %11 The machine verifier essentially complains that the rest of the register is undefined (a subregister write implies a "read" of the other parts). So the problem is that dead-mi-elimination has removed the previously existing defines of %5.sub0.

On May 19, 2011, at 7:47 AM, Jonas Paulsson wrote: > Hi, > > I am combining 16-bit registers to a 32 bit register in order to make a wide store, as per below: > > 732 %reg16506:hi16<def,dead> = COPY %reg16445<kill>; > 740 %reg16506:lo16<def> = COPY %reg16468<kill>; > 748 %r3<def,dead> = store %reg16506<kill>, %r3, > > As you can

Hi, I am combining 16-bit registers to a 32 bit register in order to make a wide store, as per below: 732 %reg16506:hi16<def,dead> = COPY %reg16445<kill>; 740 %reg16506:lo16<def> = COPY %reg16468<kill>; 748 %r3<def,dead> = store %reg16506<kill>, %r3, As you can see, LiveVariables has marked the high part dead, even though the super-register is used at

...ce = 10.0.0.255 # Speedup options for database use: Whether you are using Microsoft Access, # FoxPro, Quickbooks or CA-Clipper, with any multi-user fileserver database # application there are configurations. Please note to use the 95 and NT client # side program ccreg.zip can be found under //nas_server/Source/Linux/samba/clientfix # Please note that I have experianced problems with onboard and or cheaper # networkcards when playing with "socket options" (22/10/03) socket options = TCP_NODELAY SO_SNDBUF=8192 SO_RCVBUF=8192...

...); > BBSizes[MBB->getNumber()] -= delta; > MachineBasicBlock* SplitBB = next(MachineFunction::iterator(MBB)); > AdjustBBOffsetsAfter(SplitBB, -delta); > @@ -1243,18 +1243,18 @@ > BuildMI(MBB, TII->get(MI->getOpcode())).addMBB(NextBB) > .addImm(CC).addReg(CCReg); > Br.MI = &MBB->back(); > - BBSizes[MBB->getNumber()] += ARM::GetInstSize(&MBB->back()); > + BBSizes[MBB->getNumber()] += TII->GetInstSize(&MBB->back()); > BuildMI(MBB, TII->get(Br.UncondBr)).addMBB(DestBB); > - BBSizes[MBB->getNumber()] +...

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And