Here's a reworked patch to mark instructions and operands as vector or
scalar.
It uses TableGen to infer the flags from types, allowing the user to override
with a "let isVector = 0" clause.
I decided to forego classifying MachineMemOperands for now in the interests of
getting this piece in. I still think we should add type information to
MachineMemOperands. Why throw away perfectly good information we have at
the time they're created?
Obviously I will submit the patch in pieces but I wanted to show what the
overall result will be.
Please review. Thanks!
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vector.patch
Type: text/x-diff
Size: 11401 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20091204/e2271362/attachment.patch>
On Friday 04 December 2009 16:44, David Greene wrote:> Here's a reworked patch to mark instructions and operands as vector or > scalar. It uses TableGen to infer the flags from types, allowing the user > to override with a "let isVector = 0" clause. > > I decided to forego classifying MachineMemOperands for now in the interests > of getting this piece in. I still think we should add type information to > MachineMemOperands. Why throw away perfectly good information we have at > the time they're created? > > Obviously I will submit the patch in pieces but I wanted to show what the > overall result will be. > > Please review. Thanks!Ping? -Dave
On Monday 07 December 2009 13:47, David Greene wrote:> On Friday 04 December 2009 16:44, David Greene wrote: > > Here's a reworked patch to mark instructions and operands as vector or > > scalar. It uses TableGen to infer the flags from types, allowing the user > > to override with a "let isVector = 0" clause. > > > > I decided to forego classifying MachineMemOperands for now in the > > interests of getting this piece in. I still think we should add type > > information to MachineMemOperands. Why throw away perfectly good > > information we have at the time they're created? > > > > Obviously I will submit the patch in pieces but I wanted to show what the > > overall result will be. > > > > Please review. Thanks! > > Ping?Ping? -Dave
On Dec 4, 2009, at 2:44 PM, David Greene wrote:> Here's a reworked patch to mark instructions and operands as vector > or scalar. > It uses TableGen to infer the flags from types, allowing the user to > override > with a "let isVector = 0" clause. > > I decided to forego classifying MachineMemOperands for now in the > interests of > getting this piece in. I still think we should add type information > to > MachineMemOperands. Why throw away perfectly good information we > have at > the time they're created?Your diff isn't clean and won't apply to mainline, you have some previously committed changes, like the extraneous #include of MachineMemOperand.h. More significantly, as I mentioned before, I don't think this is a great way to go. For MachineOperands on X86, you either have a register operand (which is obvious whether it is vector or not) or you have a collection of addressing mode stuff, which is decomposed and "not an operand". What is the expected use case for "vector" operands that are not registers? What do you plan to use this information for? -Chris
On Tuesday 08 December 2009 13:23, Chris Lattner wrote:> Your diff isn't clean and won't apply to mainline, you have some > previously committed changes, like the extraneous #include of > MachineMemOperand.h.Yes, I know. I was simply asking for a review. I can regenerate it if you wish.> More significantly, as I mentioned before, I don't think this is a > great way to go. For MachineOperands on X86, you either have a > register operand (which is obvious whether it is vector or not) or you > have a collection of addressing mode stuff, which is decomposed and > "not an operand".I don't see how a register MachineOperand is obviously a vector unless there's type information somewhere that I'm missing. That decomposed addressing stuff is interesting, because if one of your addressing compoenent is a vector, you have a gather-scatter situation.> What is the expected use case for "vector" operands that are not > registers? What do you plan to use this information for?Well, as I explained earlier, I wanted to add type information to MachinbeMemOperands so I could comment spills as either Vector or Scalar. That's less important now, so that's why I decided to drop that for the time being. I still think type information in the MachineMemOperand is a good idea because it preserves useful information longer. But I'll come back to that if/when I have a stronger need. As for this patch, which marks instructions and operands as vector, I don't have an immediate use other than it originally drove the vector/scalar spill marking before Evan (quite rightly) asked for a more general approach to deciding if an instruction is a vector operation. At that point I decided that the MachineMemOperand needed to change to mark spills. In the future, I could imagine this being useful for doing peeps and other things where we might like to know the cost of an instruction, analyze the % of a function vectorized, etc. For now, I just don't want to lose this work. Even just applying this and immediately reverting it is better than nothing because it will at least be preserved in the repository history. -Dave