search for: copycost

On 2012 2 2, at 08:40, Jeroen Dobbelaere <Jeroen.Dobbelaere at synopsys.com> wrote: > I was able to get rid of the 'moves' by setting the copycost to -1. > For getting rid of the spills, I was forced to introduce custom nodes, that pass the CC register > through 'glue'. > > Having a property to register classes that identifies a 'glue-like' behavior would make sense to me. I think setting CopyCost = -1 more or le...

Well, I actually glue my condition-registers already, but as far as I know this only affects the scheduling from the DAG to the MachineFunction. It still happened that a register allocator at -O0 would spill this register for no reason at all in between these instructions. The CopyCost attribute would help me, if the register allocators would factor it in with the spillWeight calculation. I suppose this would be fairly simple to implement, given that all the register allocators except -fast use the CalcSpillWeights class, where it could be included. Would this make sense to you a...

...c)>; def BCC : Instr< (outs), (ins CCReg:$cc, brtarget:$addr), "bcc $addr", [(brcond CCReg:$cc, bb:$addr)] >; This worked, but for more complex programs, llvm tries to generate code to move CC and to spill CC. I was able to get rid of the 'moves' by setting the copycost to -1. For getting rid of the spills, I was forced to introduce custom nodes, that pass the CC register through 'glue'. Having a property to register classes that identifies a 'glue-like' behavior would make sense to me. Greetings, Jeroen Dobbelaere

...If you have a compare instruction that generates a flag and a branch instruction 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...

...e instruction that generates a flag and a branch instruction 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 th...

...is always done by LLVM? Is it me who is telling to LLVM to do it? I'd appreciate 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), !st...

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

> The best fix is to teach this scheduler how to deal with these > dependencies. :-) > > If you just want a check, I think it's easier to just check register > class's copy cost. -1 means it's extremely expensive to copy registers > in the particular register class. Evan, I am not sure what you mean by "if you just want a check" - I was trying to point out

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

One of my reasons for lowering things early is that I need to get an accurate count of the size of things. Some of the pseudos even have instructions like compare immediate, which in Mips 16 has two forms depending on the magnitude of the immediate field. Though I suppose it's possible to leave things as a pseudo and calculate their size, though I'm not sure where I could store the

...er, we need to store the tile register to memory and load the > data from memory to another register. So a lot of code for live > interval split in Greedy RA is unnecessary for tile register allocation. > Yes, but this just means that you need to support copying through memory. Setting CopyCost = -1 in X86RegisterInfo.td might help as well. > 4.Compiler can support register spill, but spill should be avoided for > performance benefit. We prefer reporting warning on register spill, so > that user can realize it and adjust their code to avoid register spill. > If you want t...

> 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

AFAIK, You have two choices: use a pseudo that is lowered into separate instructions later as part of asm emission, or use MI bundles. The former is generally what existing targets use for this sort of thing, but perhaps the second would work better for you. Cameron On Feb 16, 2013, at 8:37 PM, Reed Kotler <rkotler at mips.com> wrote: > Some of my pseudos do conditional branch .+4 and

...copy tile register, we need to store the tile register to memory and load the data from memory to another register. So a lot of code for live interval split in Greedy RA is unnecessary for tile register allocation. Yes, but this just means that you need to support copying through memory. Setting CopyCost = -1 in X86RegisterInfo.td might help as well. 5. Compiler can support register spill, but spill should be avoided for performance benefit. We prefer reporting warning on register spill, so that user can realize it and adjust their code to avoid register spill. If you want to emit a dia...

Hi, Yuanke, Thanks for writing this up. Let me back up a bit because the scheme I proposed last week doesn't work without further modification: within a particular "configuration region" (i.e., the code in between the LDTILECFG and the TILERELEASE (or next LDTILECFG)), each tile register can only be used with one shape, and in addition, no register can have its shape changed