similar to: [LLVMdev] tablegen changes

I ended up settling on a scheme which I'm not completely happy with but it's the best I can see to do. const MCInstrDesc& AddiuSpImm(int64_t Imm) const; and then if (isInt<16>(-Remainder)) BuildMI(MBB, I, DL, AddiuSpImm(-Remainder)).addImm(-Remainder); So the AddiuSpImm choses which instruction description to use depending on the immediate value and then

On 02/15/2013 03:07 PM, Jakob Stoklund Olesen wrote: > On Feb 15, 2013, at 1:21 PM, Reed Kotler <rkotler at mips.com> wrote: > >> I want to have some functions that create machine instructions, not specifying which machine function or basic block or iterator they are part of. > All machine instructions must be created by a machine function. It provides the context for memory

Actually, SP is already not in the mips 16 register class but there is some C++ code that is common to mips32, mips64 and mips16 that is wanting to use SP. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. Maybe I'm shooting myself in the foot there. I don't know that code too well so maybe I need to look into it. There are

On Sep 20, 2012, at 11:44 PM, Reed Kotler <rkotler at mips.com> wrote: > Actually, SP is already not in the mips 16 register class but there is some C++ code that is common to mips32, mips64 and mips16 that is wanting to use SP. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. > ARM has a similar problem. The InstrInfo

Turned out to be a rather simple fix. Just copied SP to a virtual register in the beginning of the function. Then added an extra operand to the DAGs with stack reference load/store, with the extra operand equal to this virtual register if the Parent of the address is a LOAD/STORE of an 8 or 16 bit quantity. It worked fine. When needed SP got copied to a mips 16 register and when the SP alias

Ok. That's a somewhat different problem, then. Devil will be in the details of what you want to do. A few options. First is to always have a standard frame pointer register available and reference off of that. Caveat: dynamic stack realignment and vararrays muck with that more than a bit. Second is what gcc is doing and reserve a register just for this in addition to the frame register.

This variant works: class ArithLogicRTest16<string I, SDNode OpNode, bit isComm = 0>: FRRR16<!cast<FRRR16_ins>(I).f, (outs CPU16Regs:$rx), (ins CPU16Regs:$ry, CPU16Regs:$rz), // !cast<FRRR16_ins>(I).OutOperandList, // !cast<FRRR16_ins>(I).InOperandList, !cast<FRRR16_ins>(I).AsmString, [(set CPU16Regs:$rx,

We already divided out our classes as you did for ARM. The problem here is that we have a store/load byte/halfword to/from a Frame object. We know at that time that it's not going to be possible to store it using SP because there is only such instructions for store/load of a word. What we would want to do is to move SP into a Mips 16 register and then do a indexed load/store off of that

I think that what I did originally should have worked and the bug was correct as I reported it. Here is an alternate implementation which has the same problem. class ArithLogicRTest16<string I, SDNode OpNode, bit isComm = 0>: FRRR16<!cast<FRRR16_ins>(I).f, !cast<FRRR16_ins>(I).OutOperandList, !cast<FRRR16_ins>(I).InOperandList,

class FRRR16_ins<bits<2> _f, string asmstr, list<dag> pattern, InstrItinClass itin> : // ... This class has template args. You don't specify them in the first template arg of class ArithLogicR16<FRRR16_ins I, SDNode OpNode, bit isComm = 0>: // ... --Sean Silva On Tue, Jul 3, 2012 at 2:29 PM, reed kotler <rkotler at mips.com> wrote: > Not sure what you mean.

Not sure what you mean. I.OutOperandList == (outs CPU16Regs:$rx) I.InOperandList == (ins CPU16Regs:$ry, CPU16Regs:$rz) On 07/02/2012 09:26 PM, Sean Silva wrote: > I think you're missing the template args for `FRRR16_ins` in the first > argument. The switch in TGParser::ParseType() doesn't cover the case > of types with template args though... which makes me wonder what is

I'm still seeing this problem. On 11/28/2013 09:37 AM, NAKAMURA Takumi wrote: > It is r195843 and fixed in r195905, FYI. > > 2013/11/29 Reed Kotler <rkotler at mips.com>: >> I"m getting build errors I think from one of your patches O tjoml. >> >> You need to have a build area that builds with clang and does warnings as >> errors to avoid these

What is the purpose of tablegen created files for fast-isel? If I make the following change to Makefile in lib/Target/Mips BUILT_SOURCES = MipsGenRegisterInfo.inc MipsGenInstrInfo.inc \ MipsGenAsmWriter.inc MipsGenCodeEmitter.inc \ MipsGenDAGISel.inc MipsGenCallingConv.inc \ - MipsGenSubtargetInfo.inc MipsGenMCCodeEmitter.inc \ +

According to the TableGen manual: "Each def record has a special entry called "NAME." This is the name of the def ("ADD32rr" above). In the general case def names can be formed from various kinds of string processing expressions and NAME resolves to the final value obtained after resolving all of those expressions. The user may refer to NAME anywhere she desires to

On 03/25/2012 07:52 PM, greened at obbligato.org wrote: > Reed Kotler<rkotler at mips.com> writes: > >> I agree that for multiclass it works more how you would expect it to. >> >> So, I don't think that NAME should be ? as in the example I gave. > I think you are right. I never tested it with regular classes because I > hadn't come across a use case.

It is r195843 and fixed in r195905, FYI. 2013/11/29 Reed Kotler <rkotler at mips.com>: > I"m getting build errors I think from one of your patches O tjoml. > > You need to have a build area that builds with clang and does warnings as > errors to avoid these issues on putback. > > here is my configure step for example: > /home/rkotler/llvm_trunk/configure

I think you're missing the template args for `FRRR16_ins` in the first argument. The switch in TGParser::ParseType() doesn't cover the case of types with template args though... which makes me wonder what is going on inside of TableGen to make `I.f` and `I.AsmString` valid... --Sean Silva On Mon, Jul 2, 2012 at 8:07 PM, reed kotler <rkotler at mips.com> wrote: > I've filed

Hi Sean, Glad to hear there is clean up of tablegen going on. Just for the record, I don't know what you are referring to regarding some comment of mine at my talk about 10K LOC. I don't know how big tablegen is itself nor how much code has been written in it so I would not have ventured such a guess. The idea of totally replacing the tablegen language came up at the talk during the

I have an approved target independent putback and i've run all that we have at Mips as well as on x86 " make TEST=simple" Is there anything else that is easy to run that I can do before doing the commit? The patch touches a number of basic classes so I'm just trying to err on the side of caution.

I definitely trust what you say now with time to think at your keyboard over what you said on the spot in a live presentation. The comment that I was referring to was: 36:44 of http://llvm.org/devmtg/2012-04-12/videos/Reed_Kotler-mobile.mov "there's not really more than a couple thousand lines of .td ... I mean there's not tons of this code so if we had to use a different one I