On Tuesday 01 December 2009 15:04, Chris Lattner wrote:> > The size is actually calculated from an EVT nearly everywhere (and > > where it's not it should be easy to add). We could just replace the > > size with the EVT and have more information. > > It sounds like you're looking for a property of an instruction, not an > operand. If you're looking for vector instructions, that should be > captured in TargetInstrInfo, not in MachineInstrs/Operands.Yes, I've written all that support. But that doesn't cover MachineMemOperands. AFAIK there's no machine-independent way to tell which instruction operands make up a MachineMemOperand. And even then, that would only tell you about the compoenents that make up the address, not the data itself. Note that having a machine-independent way to associate MachineOperands with MachineMemOperands would also be highly useful, but that will come later. It's common to have an instruction that takes both vector and scalar data. The x86 insert/extract instructions, for example. Often we'll want to know which operands are the vector ones and if they come from memory, we need that information in the MachineMemOperand. -Dave
On Dec 1, 2009, at 1:10 PM, David Greene wrote:> On Tuesday 01 December 2009 15:04, Chris Lattner wrote: > >>> The size is actually calculated from an EVT nearly everywhere (and >>> where it's not it should be easy to add). We could just replace the >>> size with the EVT and have more information. >> >> It sounds like you're looking for a property of an instruction, not an >> operand. If you're looking for vector instructions, that should be >> captured in TargetInstrInfo, not in MachineInstrs/Operands. > > Yes, I've written all that support. But that doesn't cover > MachineMemOperands. AFAIK there's no machine-independent way to tell which > instruction operands make up a MachineMemOperand. And even then, that would > only tell you about the compoenents that make up the address, not the data > itself. Note that having a machine-independent way to associate > MachineOperands with MachineMemOperands would also be highly useful, but > that will come later.Again, you're saying that you need something without explaining what for. :) We don't have a strong model for what is an 'operand' (memoperands are not bound to a particular list of MachineOperands). If you want to fix that problem, the fix isn't to add an MVT to memoperands. -Chris
On Wednesday 02 December 2009 01:26, Chris Lattner wrote:> > Yes, I've written all that support. But that doesn't cover > > MachineMemOperands. AFAIK there's no machine-independent way to tell > > which instruction operands make up a MachineMemOperand. And even then, > > that would only tell you about the compoenents that make up the address, > > not the data itself. Note that having a machine-independent way to > > associate MachineOperands with MachineMemOperands would also be highly > > useful, but that will come later. > > Again, you're saying that you need something without explaining what for.No, no, I don't need this particular mapping. What I need is information to determine whether a MachineMemOperand is of vector type. Hence the EVT would be useful. I don't care right now which MachineOperands it aggregates. -Dave