search for: addrreg

...m writing a new back-end for a new architecture. First, I'll do some "tests" with an existing back-end (I chose the Sparc back-end). My architecture has special address-registers and I want to add such new address-registers to my Sparc back-end. 1) I defined a new register call AddrRegs 2) I registered the class AddrRegs (addRegisterClass(MVT::iPTR, .. )) 3) I added method addPointerRegClass() to my InstrInfo class The compiler generates the some code as before, but that seems to be ok, because I haven't used ptr_rc yet. 4) I changed the address mode MEMri: def MEMri :...

...ck-end for a new architecture. First, I'll do > some "tests" with an existing back-end (I chose the Sparc back-end). > My architecture has special address-registers and I want to add such > new address-registers to my Sparc back-end. > > 1) I defined a new register call AddrRegs > 2) I registered the class AddrRegs (addRegisterClass(MVT::iPTR, .. )) > 3) I added method addPointerRegClass() to my InstrInfo class > > The compiler generates the some code as before, but that seems to > be ok, because I haven't used ptr_rc yet. > > 4) I changed the a...

...o my Sparc back-end. >> .... >> The GlobalAddress for variable c is replaced by an ADD(HI(c), LO >> (c)) during lowering. I assume the code-generator cant place values >> in the address registers? All address-registers are elements in the >> register sets IntRegs and AddrRegs. > > /// F3_12 multiclass - Define a normal F3_1/F3_2 pattern in one shot. > multiclass F3_12<string OpcStr, bits<6> Op3Val, SDNode OpNode> { > .... > } > > defm ADD : F3_12<"add", 0b000000, add>; > > Instruction ADD output register class is...

in llvm-3.6.2.src 1. when I put this around one of my instruction definitions in my target "InstrInfo.td" file, let TwoOperandAliasConstraint = "$dst = $rs1" in { } I do not see any TIED_TO in the generated GenInstrInfo.inc file for the OperandInfo used by the instruction, the question is what am I doing wrong ? 2. I've noticed that TwoOperandAliasConstraint

...em is that my target has separate address and data registers. The way I’d like to try getting better reg-alloc than I am now is to bring out the difference as Early as possible, so I have added p16, p32, p64 to the enum in “MachineValueType.h” And I have called addRegisterClass(MVT::p32, &XyzAddrRegsRegClass); And I have an override for virtual TargetLowering::getPointerTy() that returns MVT::p32, And some other minor changes that altogether cause virt-regs that contain pointers To get my AddrRegs reg-class rather than the “GPR” reg-class that i32 types get. So far so good, except tha...

I don’t quite follow why you are doing something like this. What is the advantage of this instead of just attaching the AddrRegs regsister class as the register class for your instruction? So that you would have an ADD instruction like %AddrRegOut = ADD %AddrRegIn1, %AddrRegIn2 What kind of problematic regalloc are you trying to avoid with introducing a new backend data type? Marcello > On 25 May 2016, at 19:07, Lawre...

...long with a class for every type in MachineValueTypes.h On Wed, May 25, 2016 at 8:12 PM, Marcello Maggioni via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I don’t quite follow why you are doing something like this. > > What is the advantage of this instead of just attaching the AddrRegs > regsister class as the register class for your instruction? > So that you would have an ADD instruction like > %AddrRegOut = ADD %AddrRegIn1, %AddrRegIn2 > > What kind of problematic regalloc are you trying to avoid with introducing > a new backend data type? > > Marcello...

...ry type in MachineValueTypes.h On Wed, May 25, 2016 at 8:12 PM, Marcello Maggioni via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: I don’t quite follow why you are doing something like this. What is the advantage of this instead of just attaching the AddrRegs regsister class as the register class for your instruction? So that you would have an ADD instruction like %AddrRegOut = ADD %AddrRegIn1, %AddrRegIn2 What kind of problematic regalloc are you trying to avoid with introducing a new backend data type? Marcello On 25 May 2016, at 19:07, Lawrence, P...

...chineValueTypes.h > > > > On Wed, May 25, 2016 at 8:12 PM, Marcello Maggioni via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > I don’t quite follow why you are doing something like this. > > > > What is the advantage of this instead of just attaching the AddrRegs > regsister class as the register class for your instruction? > > So that you would have an ADD instruction like > > %AddrRegOut = ADD %AddrRegIn1, %AddrRegIn2 > > > > What kind of problematic regalloc are you trying to avoid with introducing > a new backend data type...

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? Spill-free register allocation sounds great, why not do it for all register classes? > , and a register allocator would have to implement register pairing.

Hi, My target has special requirements during register allocation - there is both a need to handle register pairing and to never spill a flag result reg-class (which might happen at -O0 for no obvious reason). Since neither of these issues seems to be supported, I have tried to pre-allocate these registers in the preRA pass. This has resulted in "using undefined physical register"

...iring rule defined for any such occurence. Possibly, one could add a Constraint per instruction def as well to indicate the use of the register pairing rule, and to allow instances where it does not apply. PBQP extension (suggestion) ====================== Tablegen: def regPair : registerPair<AddrReg0, OffsReg0>, ~or~ def regPair: registerPairing<AddrReg0, [OffsReg0, OffsReg1, OffsReg2]>; ~or~ ?? in the instruction such as a load: ld dst, addrReg, offsReg then PBQP must follow the rule and only allocate legal combinations of addrReg and offsReg. I beleive this should work by setti...

Hi Peter, I would recommend looking into the implementation of the matcher if you want to add more builtin types: utils/TableGen//DAGISelMatcherGen.cpp That being said, you can define your own types without having to go through that hassle. E.g., from AArch64 def simm9 : Operand<i64>, ImmLeaf<i64, [{ return Imm >= -256 && Imm < 256; }]> { let ParserMatchClass =

Dumb question about llvm-tblgen for "XyzGenInstrInfo.inc" If I have a pattern in my dot-td-file like this [(set i32:$dst (add i32:$rs1, i32:$rs2))] The question is where does the token "i32" come from, I don't see any definitions for i1, i8, i16, i32, ... in include/llvm/Target/*.td while I do see definitions for tokens like