[LLVMdev] Simplifing the handling of pre-legalize vector nodes

[Dan Gohman]

Right now there are special SelectionDAG node kinds for operations on
"abstract" vector types (VLOAD, VADD, and all the rest), and a special
MVT::Vector ValueType for them. These nodes carry two additional operands,
constants which specify the vector length and element type. All of this is
only used before legalize; then they are replaced with regular node kinds
and value types.

It seems that a number of things would be considerably simpler if the
pre-legalize nodes could use the same node kinds as post-legalize; the only
thing preventing that is that the MVT::ValueType enum isn't able to describe
vector types with arbitrarily long vector lengths.

I'm currently considering ways to make this possible. One idea is to rename
the MVT::ValueType enum to something else and make MVT::ValueType a plain
integer type. Values beyond the range of the original enum are interpreted
as indices into a UniqueVector which holds pairs of vector lengths and
element types. This would require most of the ValueType utility routines
to be aware of the new kinds of ValueTypes so that they could handle them
properly, but once that's done, it would allow vector nodes to be handled
consistently between pre-legalize and post-legalize, without obscure
constructs like
  ... blahblah->getNumOperands()-2 ...
  ... *(blahblah->op_end()-1) ...
to get the vector length and/or element type in the pre-legalize form.

It would make -view-legalize-dags and earlier DAG drawings a lot easier to
read in DAGS with vector nodes, because they wouldn't need to be edges from
each vector node up to the common element type node and vector length node.

Finally, and of particular interest for me, it may help with the next steps
beyond PR400, as it would allow vector loads to use plain LoadSDNode nodes
instead of VLOAD, and thus have an alignment, not to mention a volatile flag
and alias information, in a consistent manner with regular loads.

Before I do much more experimentation with this, I wanted to run the idea by
the list to see what feedback it might get. Has anyone thought about doing
this before? Are there other approaches that might be better?

Another idea is to get rid of the ValueType concept altogether and just use
Type* for everything. I don't know how this would work with various
tablegen'd pieces of code though.

Dan

-- 
Dan Gohman, Cray Inc.