search for: mipsregisterinfo

On Sat, May 7, 2011 at 12:33 PM, Eric Christopher <echristo at apple.com> wrote: > > On May 5, 2011, at 11:26 PM, Liu wrote: > >>  some some type errors in the commentary of *.td file. >> such as: >> lib/Target/Mips/MipsInstrFormats.td >> MipsRegisterInfo.td - Mips Register defs >> it should be >> MipsInstrFormats.td - Mips Instruction Formats >> >> lib/Target/Mips/MipsInstrInfo.td >> MipsInstrInfo.td - Mips Register defs >> it should be >> MipsInstrInfo.td - Target Description for Mips Target >> >&...

Hi all, I find some some type errors in the commentary of *.td file. such as: lib/Target/Mips/MipsInstrFormats.td MipsRegisterInfo.td - Mips Register defs it should be MipsInstrFormats.td - Mips Instruction Formats lib/Target/Mips/MipsInstrInfo.td MipsInstrInfo.td - Mips Register defs it should be MipsInstrInfo.td - Target Description for Mips Target and some thing I think it is wrong in lib/Target/Mips/MipsInstrFPU.td. Wil...

...May 7, 2011 at 12:33 PM, Eric Christopher <echristo at apple.com> wrote: >> >> On May 5, 2011, at 11:26 PM, Liu wrote: >> >>> some some type errors in the commentary of *.td file. >>> such as: >>> lib/Target/Mips/MipsInstrFormats.td >>> MipsRegisterInfo.td - Mips Register defs >>> it should be >>> MipsInstrFormats.td - Mips Instruction Formats >>> >>> lib/Target/Mips/MipsInstrInfo.td >>> MipsInstrInfo.td - Mips Register defs >>> it should be >>> MipsInstrInfo.td - Target Description f...

...area/asm/llvm/include/ Mips.tdIncluded from Mips.td:24: MipsInstrInfo.td:833:14: error: Instruction 'LWL' has no tokens defm LWL : LoadUnAlign32<0x22>; How does it get a token? Commenting out this code I got farther and found that a register that didn't have a formal def in MipsRegisterInfo.td would get flagged. !strconcat(instr_asm, "\t$$zero, $rs, $rt"), % tblgen -gen-asm-matcher -I ~/workarea/asm/llvm/include/ Mips.td Included from Mips.td:24: Included from MipsInstrInfo.td:1120: Mips64InstrInfo.td:173:1: error: error: unable to find operand: 'zero' def DS...

On May 5, 2011, at 11:26 PM, Liu wrote: > some some type errors in the commentary of *.td file. > such as: > lib/Target/Mips/MipsInstrFormats.td > MipsRegisterInfo.td - Mips Register defs > it should be > MipsInstrFormats.td - Mips Instruction Formats > > lib/Target/Mips/MipsInstrInfo.td > MipsInstrInfo.td - Mips Register defs > it should be > MipsInstrInfo.td - Target Description for Mips Target > > and some thing I think it is w...

..., "F0", [F0, F1]>; /// Mips Double point precision FPU Registers in MFP64 mode. def D0_64 : AFPR64<0, "F0", [F0]>; Notice that we currently need the symbolic name to be different (F0/D0/D0_64) for use in the codegen. The examples here are from lib/Target/Mips/MipsRegisterInfo.td. Do I just need to use/write another register parser? Or is there a clever way of defining the context sensitive Mips register set? Thanks, Jack -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120131/37...

...used by the instruction printer. That's saying there's a variant in the multi class expansion that doesn't have a string associated with it that can be used to derive the syntax. > Commenting out this code I got farther and found that a register that didn't have a formal def in MipsRegisterInfo.td would get flagged. > > !strconcat(instr_asm, "\t$$zero, $rs, $rt"), > > % tblgen -gen-asm-matcher -I ~/workarea/asm/llvm/include/ Mips.td > Included from Mips.td:24: > Included from MipsInstrInfo.td:1120: > Mips64InstrInfo.td:173:1: error: error: unable to...

At least or Mips, this line seems extraneous. I removed it and and all consequential uses of that (400 changes to MipsRegisterInfo.td) and make check for mips still works. Am running our full test sequence now. This Mips part of this was copied from the Sparc port. Similar problems in other ports. Seems this has just been copied many times to new ports. On 03/21/2012 02:58 PM, reed kotler wrote: > The field Num seems to...

...> > /// Mips Double point precision FPU Registers in MFP64 mode. > def D0_64 : AFPR64<0, "F0", [F0]>; > > Notice that we currently need the symbolic name to be different (F0/D0/D0_64) for use in the codegen. > > The examples here are from lib/Target/Mips/MipsRegisterInfo.td. > > Do I just need to use/write another register parser? Or is there a clever way of defining the context sensitive Mips register set? > > Thanks, > > Jack > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu...

...eStr, PatFrag OpNode> : LOAD<SizeOp, OpcodeStr, [(set i64:$dst, (OpNode ADDRri:$addr))]>; So I am surprised that the instruction selector finds as match for operand i64:$dst the vector register REGVEC0, which has type v8i64 as defined below, inspired from lib/Target/Mips/MipsRegisterInfo.td: def MSA128D: RegisterClass<"Connex", [v8i64], 512, (sequence "Wd%u", 0, 31)>; Can anybody help with an idea what I can do to fix this problem? Below are a few possibly useful lines from the output of llc, related to the in...

...> > /// Mips Double point precision FPU Registers in MFP64 mode. > def D0_64 : AFPR64<0, "F0", [F0]>; > > Notice that we currently need the symbolic name to be different (F0/D0/D0_64) for use in the codegen. > > The examples here are from lib/Target/Mips/MipsRegisterInfo.td. > > Do I just need to use/write another register parser? Or is there a clever way of defining the context sensitive Mips register set? > > Thanks, > > Jack > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu...

The field Num seems to have no meaning. It is not recognized by the backend tools. It does not hurt anything but should not be there. // We have banks of 32 registers each. class MipsReg<string n> : Register<n> { field bits<5> Num; let Namespace = "Mips"; } class ARMReg<bits<4> num, string n, list<Register> subregs = []> : Register<n> {

...: LOAD<SizeOp, OpcodeStr, [(set i64:$dst, (OpNode ADDRri:$addr))]>; > > So I am surprised that the instruction selector finds as match for operand > i64:$dst > the vector register REGVEC0, which has type v8i64 as defined below, inspired > from > lib/Target/Mips/MipsRegisterInfo.td: > def MSA128D: RegisterClass<"Connex", [v8i64], 512, > (sequence "Wd%u", 0, 31)>; > > Can anybody help with an idea what I can do to fix this problem? > > Below are a few possibly useful lines from the ou...

....o ../../recurse2be/build/./lib/Target/Mips/Release+Asserts/Mips16ISelDAGToDAG.o differ: byte 59954, line 71 ./lib/Target/Mips/Release+Asserts/MipsISelDAGToDAG.o ../../recurse2be/build/./lib/Target/Mips/Release+Asserts/MipsISelDAGToDAG.o differ: byte 55133, line 72 ./lib/Target/Mips/Release+Asserts/MipsRegisterInfo.o ../../recurse2be/build/./lib/Target/Mips/Release+Asserts/MipsRegisterInfo.o differ: byte 23542, line 29 ./lib/Target/Mips/Release+Asserts/MipsSEISelDAGToDAG.o ../../recurse2be/build/./lib/Target/Mips/Release+Asserts/MipsSEISelDAGToDAG.o differ: byte 83281, line 94 ./lib/Target/Mips/InstPrinter/Re...

...CMakeLists.txt index cf8bb18..1029e3c 100644 --- a/lib/Target/Mips/CMakeLists.txt +++ b/lib/Target/Mips/CMakeLists.txt @@ -32,6 +32,8 @@ add_llvm_target(MipsCodeGen MipsLongBranch.cpp MipsMCInstLower.cpp MipsMachineFunction.cpp + MipsModuleISelDAGToDAG.cpp + MipsModuleISelLowering.cpp MipsRegisterInfo.cpp MipsSEFrameLowering.cpp MipsSEInstrInfo.cpp diff --git a/lib/Target/Mips/Mips16ISelDAGToDAG.cpp b/lib/Target/Mips/Mips16ISelDAGToDAG.cpp index 00b3449..2ffd3a9 100644 --- a/lib/Target/Mips/Mips16ISelDAGToDAG.cpp +++ b/lib/Target/Mips/Mips16ISelDAGToDAG.cpp @@ -35,6 +35,11 @@ #include &qu...

On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote: > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if the > attributes changed). Do you have another solution in mind ? I don't really understand this. TargetMachine and TTI may be quite expensive to initialize. Doing so for

Hi all, There's been a recent bootstrap failure that might be covered up because of another failure. I just wanted to point this out so that people can take a look: -bw Here's the failure from our buildbot: Assertion failed: (DestReg == VirtReg && "Unknown load situation!"), function RewriteMBB, file /Volumes/Sandbox/Buildbot/llvm/build.llvm-