[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