[LLVMdev] Rework of Vector/Scalar Classification
David Greene
dag at cray.com
Tue Dec 8 12:08:59 PST 2009
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
More information about the llvm-dev
mailing list