search for: targetinstrdescriptor

...and LLVM-GCC4 and recompile, perhaps every few days or so. I've not had success in some cases building LLVM-GCC4 on a Gentoo Linux host, for perhaps the last week or so. My system compiler is GCC 4.1.1. >>> cc1: /usr/src/llvm/llvm/include/llvm/Target/TargetInstrInfo.h:151:const llvm::TargetInstrDescriptor& llvm::TargetInstrInfo::get(llvm::MachineOpCode) const: Assertion '(unsigned)Opcode < NumOpcodes' failed. /usr/src/llvm/llvm-gcc4/gcc/crtstuff.c: At top level: /usr/src/llvm/llvm-gcc4/gcc/crtstuff.c:314: internal compiler error: Aborted <<< This occurs only when building fo...

...the incomplete collection of dummy routines someone already put in. > With this patch, the fortran build dies at this point: > > cc1: llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:367: void llvm::ScheduleDAG::AddOperand(llvm: > :MachineInstr*, llvm::SDOperand, unsigned int, const llvm::TargetInstrDescriptor*, std::map<llvm::SDNode*, unsign > ed int, std::less<llvm::SDNode*>, std::allocator<std::pair<llvm::SDNode* const, unsigned int> > >&): Assertion `R > egMap->getRegClass(VReg) == RC && "Register class of operand and regclass of use don't agree!&...

...LLVM-GCC4 and recompile, perhaps every few days or so. I've not had success in some cases building LLVM-GCC4 on a Gentoo Linux host, for perhaps the last week or so. My system compiler is GCC 4.1.1. > > > cc1: /usr/src/llvm/llvm/include/llvm/Target/TargetInstrInfo.h:151:const llvm::TargetInstrDescriptor& llvm::TargetInstrInfo::get(llvm::MachineOpCode) const: Assertion '(unsigned)Opcode < NumOpcodes' failed. > /usr/src/llvm/llvm-gcc4/gcc/crtstuff.c: At top level: > /usr/src/llvm/llvm-gcc4/gcc/crtstuff.c:314: internal compiler error: Aborted > <<< > Hi Andrew,...

...>; and there are parallel definitions in X86InstrInfo.h: Pseudo = 0, RawFrm = 1, Those definitions are used in codegen, and and TableGen somehow passes the instruction format information to X86GenInstInfo.inc -- specifically, it encodes it in the TSFlags field of the TargetInstrDescriptor class. So the question is: how the information about format should be specified in .td files? I've tried this: class Format<bits<5> val> { bits<5> Value = val; } def F1 : Format<4>; class NMI<string nam> : Instruction { let Namespace = "N...

...n stubs and rip out the incomplete collection of dummy routines someone already put in. With this patch, the fortran build dies at this point: cc1: llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:367: void llvm::ScheduleDAG::AddOperand(llvm: :MachineInstr*, llvm::SDOperand, unsigned int, const llvm::TargetInstrDescriptor*, std::map<llvm::SDNode*, unsign ed int, std::less<llvm::SDNode*>, std::allocator<std::pair<llvm::SDNode* const, unsigned int> > >&): Assertion `R egMap->getRegClass(VReg) == RC && "Register class of operand and regclass of use don't agree!"'...

...ions in X86InstrInfo.h: > > Pseudo = 0, > RawFrm = 1, Exactly. > Those definitions are used in codegen, and and TableGen somehow passes the > instruction format information to X86GenInstInfo.inc -- specifically, it > encodes it in the TSFlags field of the TargetInstrDescriptor class. Yup, the TSFlags field is defined to hold TargetSpecific flags of whatever sort you want. Just the thing for holding information about how to print. > So the question is: how the information about format should be specified > in .td files? I've tried this: > But the values o...

...e collection of dummy routines someone already put in. > With this patch, the fortran build dies at this point: > > cc1: llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:367: void > llvm::ScheduleDAG::AddOperand(llvm: > :MachineInstr*, llvm::SDOperand, unsigned int, const > llvm::TargetInstrDescriptor*, std::map<llvm::SDNode*, unsign > ed int, std::less<llvm::SDNode*>, > std::allocator<std::pair<llvm::SDNode* const, unsigned int> > >&): > Assertion `R > egMap->getRegClass(VReg) == RC && "Register class of operand and > regclass of...