search for: targetoperandinfo

You can get to the MachineInstr from a MachineOperand. Then get to its TargetInstrDesc and TargetOperandInfo which has register class information. Evan On Sep 23, 2008, at 12:44 PM, Villmow, Micah wrote: > How do I determine what type of register(i.e. i32, f32, etc..) I am > accessing from a MachineOperand? I.e. how do I get to the MVT > struct, or equivalent information, from a MachineO...

...al? I'm assuming that all LiveRange entries in the LiveInterval are consistent in that if allocated to a register they would all go in the same register class. Fair assumption? If I take the first LiveRange LR from LI, look up its instruction/operand at "start" and then look at its TargetOperandInfo and send TOI::RegClass to MRegisterInfo:getRegClass, is that sufficient. It seems way overly complicated. After LiveIntervalAnalysis runs we have a set of LIs we can iterate over. What's the most efficient way to get the register classes for these intervals so I know which machine registers...

How do I determine what type of register(i.e. i32, f32, etc..) I am accessing from a MachineOperand? I.e. how do I get to the MVT struct, or equivalent information, from a MachineOperand object? Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596

...instruction with the following selection pattern (store (f32 Regs: $src), ADDRri:$addr), rather than adding a pattern such as the following: def : Pat<(store (f32 Regs:$src), ADDRri:$addr), (ST32 Regs:$src, ADDRri:$addr)>; The above pattern produced the following error because the TargetOperandInfo for the 1 operand of the store had a NULL register class. llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:304: failed assertion `RC && "Don't have operand info for this instruction!"' Why the pseudo-op doesn't have this problem, I'm not clear. Thanks -- Christ...

...ng selection pattern (store (f32 Regs: > $src), ADDRri:$addr), rather than adding a pattern such as the > following: > > def : Pat<(store (f32 Regs:$src), ADDRri:$addr), (ST32 Regs:$src, > ADDRri:$addr)>; > > The above pattern produced the following error because the > TargetOperandInfo for the 1 operand of the store had a NULL register > class. > > llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:304: failed assertion > `RC && "Don't have operand info for this instruction!"' > > Why the pseudo-op doesn't have this problem, I'm not...

...vmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Wednesday, September 24, 2008 10:22 AM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Determining the register type of a MachineOperand You can get to the MachineInstr from a MachineOperand. Then get to its TargetInstrDesc and TargetOperandInfo which has register class information. Evan On Sep 23, 2008, at 12:44 PM, Villmow, Micah wrote: How do I determine what type of register(i.e. i32, f32, etc..) I am accessing from a MachineOperand? I.e. how do I get to the MVT struct, or equivalent information, from a MachineOperand obje...

...example, in an SSE operand you want to know the type of data contained in it (32-bit [or less] or 64-bit) to generate optimal code. Just knowing that it's a 128-bit vector register that can hold 8-, 16-, 32- or 64-bit data is not enough. Getting this information into the TargetInstrInfo / TargetOperandInfo would take a fair amount of TableGen and .td file hacking, I would think. Right? -Dave

On Sep 2, 2008, at 10:42 AM, David Greene wrote: > Is there an easy way to get the MVT::ValueType of a MachineInstruction > MachineOperand? For example, the register operand of an x86 MOVAPD > should > have an MVT::ValueType of v2f64. A MOVAPS register operand should > have an > MVT::ValueType of v4f32. The short answer is no. A op of a number of different VTs can map to

Hi,    I would like to get the type of immediate value (integer) from MachineOperand Class. Currently the immediate value is being represented as int64_t. int64_t ImmVal; // For MO_Immediate.   Is it possible to find out whether the immediate value is int8, 16, 32 etc?   Note: My target has a virtual Instruction set.   Thanks in advance, -Sanjay -------------- next part -------------- An

David Greene wrote: > If I take the first LiveRange LR from LI, look up its > instruction/operand at "start" and then look at its > TargetOperandInfo and send TOI::RegClass to > MRegisterInfo:getRegClass, is that sufficient. > > It seems way overly complicated. Umm...yeah. That way be dragons. :-/ Fortunately, I found MachineFunction::getSSARegMap()->getRegClass(LI.reg) which works swimmingly. -Dav...

Is there an easy way to get the MVT::ValueType of a MachineInstruction MachineOperand? For example, the register operand of an x86 MOVAPD should have an MVT::ValueType of v2f64. A MOVAPS register operand should have an MVT::ValueType of v4f32. So given a MachineInstruction and its MachineOperands is there some easy way to derive this information? I don't see anything in TargetInstrInfo

...half Of Evan Cheng > Sent: Wednesday, September 24, 2008 10:22 AM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Determining the register type of a > MachineOperand > > You can get to the MachineInstr from a MachineOperand. Then get to > its TargetInstrDesc and TargetOperandInfo which has register class > information. > > Evan > > On Sep 23, 2008, at 12:44 PM, Villmow, Micah wrote: > > > How do I determine what type of register(i.e. i32, f32, etc..) I am > accessing from a MachineOperand? I.e. how do I get to the MVT > struct, or equival...

...Regs: >> $src), ADDRri:$addr), rather than adding a pattern such as the >> following: >> >> def : Pat<(store (f32 Regs:$src), ADDRri:$addr), (ST32 Regs:$src, >> ADDRri:$addr)>; >> >> The above pattern produced the following error because the >> TargetOperandInfo for the 1 operand of the store had a NULL register >> class. >> >> llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:304: failed assertion >> `RC && "Don't have operand info for this instruction!"' >> >> Why the pseudo-op doesn't have th...

On Feb 12, 2007, at 1:41 AM, Christopher Lamb wrote: > > selector refused to select certain ops (specifically stores) for some > instructions when the operand type wasn't the first type for the > register class. After some digging around I seem to have solved the > problem by creating bitconvert patterns between the types in the > register class like the following: > >

Hi All, I'm working on a back end for an architecture that makes use of multi- typed register classes. def MR: RegisterClass<"namespace", [type1, type2, ... ], ... > When running some preliminary tests I found that the instruction selector refused to select certain ops (specifically stores) for some instructions when the operand type wasn't the first type for the

..., std::char_traits<char>, std::allocator<char> > const&)in libLLVMEBCCodeGen.a(EBCSubtarget.cpp.o) llvm::EBCSubtarget::~EBCSubtarget()in libLLVMEBCCodeGen.a(EBCSubtarget.cpp.o) llvm::EBCSubtarget::~EBCSubtarget()in libLLVMEBCCodeGen.a(EBCSubtarget.cpp.o) "llvm::TargetOperandInfo::getRegClass(llvm::TargetRegisterInfo const*) const", referenced from: (anonymous namespace)::StackSlotColoring::PropagateForward(llvm::ilist_iterator<llvm::MachineInstr>, llvm::MachineBasicBlock*, unsigned int, unsigned int) in...