search for: operandlist

Hi all, I have reported more than enough about the space savings achieved and the associated costs, here comes the current patch for review. Since this one is substantially smaller than the previous one, I did not cut it in pieces. The front part is about headers and the rest the .cpp and other files. Cheers, Gabor -------------- next part -------------- An embedded and charset-unspecified

...trInst::GetElementPtrInst(const GetElementPtrInst &GEPI) + : Instruction(reinterpret_cast<const Type*>(GEPI.getType()), GetElementPtr, + OperandTraits<GetElementPtrInst>::op_end(this) - GEPI.getNumOperands(), + GEPI.getNumOperands()) { + Use *OL = OperandList; + Use *GEPIOL = GEPI.OperandList; + for (unsigned i = 0, E = NumOperands; i != E; ++i) + OL[i].init(GEPIOL[i], this); +} Please just move methods like this out of line when possible. +DEFINE_TRANSPARENT_OPERAND_ACCESSORS(CallInst, Value) +//void CallInst::operator delete(void *it) { +// Ope...

The macro $src, $dest used in Instruction::AsmString must be "declared" in Instruction::OperandList, right? $$ has special meaning? On 5/6/05, Chris Lattner <sabre at nondot.org> wrote: > On Fri, 6 May 2005, Tzu-Chien Chiu wrote: > > llvm/lib/Target/X86/X86InstrInfo.td: > > class X86Inst<bits<8> opcod, Format f, ImmType i, dag ops, string > > AsmStr> : I...

llvm/lib/Target/X86/X86InstrInfo.td: class X86Inst<bits<8> opcod, Format f, ImmType i, dag ops, string AsmStr> : Instruction { .... dag OperandList = ops; string AsmString = AsmStr; } def MOV32mi : Ii32<0xC7, MRM0m, (ops i32mem:$dst, i32imm:$src), "mov{l} {$src, $dst|$dst, $src}">; I cannot find any document on initializing the 'dag' type variable, and I cannot understand the syntax of "asm...

...return OperandTraits<User>::op_begin(this)[Idx]; + } + template <unsigned Idx> const Use &Op() const { + return OperandTraits<User>::op_begin(const_cast<User*>(this))[Idx]; + } + Use *allocHungoffUses(unsigned) const; + void dropHungoffUses(Use *U) { + if (OperandList == U) { + OperandList = 0; + NumOperands = 0; + } + Use::zap(U, U->getImpliedUser(), true); + } At a very brief scan, it looks like allocHungoffUses and dropHungoffUses can be made protected, not public. And maybe those Op things too. Hmm, and why the operand index for Op is a...

On Fri, 6 May 2005, Tzu-Chien Chiu wrote: > llvm/lib/Target/X86/X86InstrInfo.td: > class X86Inst<bits<8> opcod, Format f, ImmType i, dag ops, string > AsmStr> : Instruction { > .... > dag OperandList = ops; > string AsmString = AsmStr; > } > > def MOV32mi : Ii32<0xC7, MRM0m, (ops i32mem:$dst, i32imm:$src), > "mov{l} {$src, $dst|$dst, $src}">; > > I cannot find any document on initializing the 'dag' type variable, > and I canno...

I am trying to write a skeleton of an ARM back end. I have declared the following class class InstARM<dag ops, string asmstr, list<dag> pattern> : Instruction { let Namespace = "ARM"; dag OperandList = ops; let AsmString = asmstr; let Pattern = pattern; } and defined three instructions (ldr, str, and mov). The problem is that, in the generated code, the namespace isn't used everywhere I expected. For example, in ARMAsmPrinter::printInstruction, the PHI instruction doesn't has a...

...le for llvm::CallInst+16>, VTy = 0x61035c0, UseList = 0x61d3310, NameAndIsUsedByMD = {Value = 0}, SubclassID = 68 'D', HasValueHandle = 0 '\000', SubclassOptionalData = 0 '\000', SubclassData = 0, NumOperands = 3, static MaximumAlignment = 536870912}, OperandList = 0x61b8e80} (gdb)

...at in the > same order that operands are defined. This seems like a bad > dependence to me, and that TableGen should match the name of field > declared in the instruction with the name of the operand in order > to determine which operand of the MI to use > . Yes, instruction OperandList corresponds to MachineInstr operands ordering. Are you saying MachineInstr should look up specific operand by name? > See CodeEmitterGen.cpp:170 and neighborhood. > > Unfortunately there are naming discrepancies between the > instruction format fields and the operand names in all...

...* multiclass Clr { def _ : ALU<"clr"> {let InstOp = 0b11;} } ----------------------------------------- after compiling the code, I receive the following error: *llvm-tblgen: /llvm/utils/TableGen/CodeGenInstruction.h:186: std::pair<unsigned int, unsigned int> llvm::CGIOperandList::getSubOperandNumber(unsigned int) const: Assertion `i < OperandList.size() && "Invalid flat operand #"' failed.* How can I define an instruction with no operand? In ARM there is a similar instruction like "CLREX" but I don't understand why in the assertion...

...etail :-). My biggest concern is how this is encoded in the SDNode. It'd be good to avoid making MemSDNode bigger, but there are a variety of ways that exiting bits can be made available. NodeType doesn't need all 16 of its bits, for example, and OperandsNeedDelete could be merged with OperandList with a PointerIntPair if needed. How are you representing movnt in LLVM IR, with an intrinsic? Dan

...> Output from make: > > llvm[0]: Building SPU.td code emitter with tblgen > tblgen: /work/scottm/llvm/utils/TableGen/CodeGenInstruction.h:118: > std::pair<unsigned int, unsigned int> > llvm::CodeGenInstruction::getSubOperandNumber(unsigned int) const: > Assertion `i < OperandList.size() && "Invalid flat operand #"' failed. > make: *** > [/work/scottm/llvm/obj/i686-unknown-linux-gnu/lib/Target/IBMCellSPU/ > Debug/SPUGenCodeEmitter.inc.tmp] > Aborted > > Whiskey Tango... Foxtrot? Please file a bug with a reduced test case for it. Eva...

...or ;-). > The second is counterbalanced with a faster access to the Use object > in most cases: > With exception of PHINode and SwitchInst, the getOperand() function > (if called on a specialized "this" pointer) does a "this"-relative > access instead of getting OperandList pointer first and going thru > that. This was the case before for fixed-arity instructions, but now > it applies to variadic ones too that cannot perform operand list > resizing. > > Some things got faster, like > 1) getOperand access on (say) CallInst is now fetching operands fro...

I noticed that the TableGen code emitter generator assumes that the instruction fields are declared in the instruction format in the same order that operands are defined. This seems like a bad dependence to me, and that TableGen should match the name of field declared in the instruction with the name of the operand in order to determine which operand of the MI to use . See

...s not sooo inefficient, anyway. The second is counterbalanced with a faster access to the Use object in most cases: With exception of PHINode and SwitchInst, the getOperand() function (if called on a specialized "this" pointer) does a "this"-relative access instead of getting OperandList pointer first and going thru that. This was the case before for fixed-arity instructions, but now it applies to variadic ones too that cannot perform operand list resizing. Some things got faster, like 1) getOperand access on (say) CallInst is now fetching operands from relative to "this&quot...

...[(retflag)]>; } } Output from make: llvm[0]: Building SPU.td code emitter with tblgen tblgen: /work/scottm/llvm/utils/TableGen/CodeGenInstruction.h:118: std::pair<unsigned int, unsigned int> llvm::CodeGenInstruction::getSubOperandNumber(unsigned int) const: Assertion `i < OperandList.size() && "Invalid flat operand #"' failed. make: *** [/work/scottm/llvm/obj/i686-unknown-linux-gnu/lib/Target/IBMCellSPU/Debug/SPUGenCodeEmitter.inc.tmp] Aborted Whiskey Tango... Foxtrot?

...er that operands are defined. This seems like a bad >> dependence to me, and that TableGen should match the name of field >> declared in the instruction with the name of the operand in order >> to determine which operand of the MI to use >> . > > Yes, instruction OperandList corresponds to MachineInstr operands > ordering. Are you saying MachineInstr should look up specific > operand by name? > >> See CodeEmitterGen.cpp:170 and neighborhood. >> >> Unfortunately there are naming discrepancies between the >> instruction format field...

...> UseList = 0x61d3310, NameAndIsUsedByMD = {Value = 0}, > SubclassID = 68 'D', > HasValueHandle = 0 '\000', SubclassOptionalData = 0 '\000', > SubclassData = 0, NumOperands = 3, static MaximumAlignment = > 536870912}, > OperandList = 0x61b8e80} > (gdb) > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> > http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >...

...concern is how this is encoded in the SDNode. It'd be > good to avoid making MemSDNode bigger, but there are a variety of ways > that exiting bits can be made available. NodeType doesn't need all 16 > of > its bits, for example, and OperandsNeedDelete could be merged with > OperandList with a PointerIntPair if needed. *shudder* Undefined behavior? No thanks. Right now, the lower five bits of SubclassData are used to encode various things for memory SDNodes. One of those is the volatile bit. This leaves 10 bits for alignment information, meaning we can represent alignments u...

..., VTy = > 0x61035c0, > UseList = 0x61d3310, NameAndIsUsedByMD = {Value = 0}, SubclassID = 68 > 'D', > HasValueHandle = 0 '\000', SubclassOptionalData = 0 '\000', > SubclassData = 0, NumOperands = 3, static MaximumAlignment = > 536870912}, > OperandList = 0x61b8e80} > (gdb) > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- An HTML attachment was...