[LLVMdev] LLVMdev Digest, Vol 80, Issue 13

[David A. Greene]

Peter Lawrence <peterl95124 at sbcglobal.net> writes:

> Andrew, your response highlights a naming problem in LLVM, which is
> that "array" and "vector" mean the same thing in normal computer
> language and compiler theory usage, so it is inconvenient and
> misleading within LLVM to give one a very specific meaning that is
> different from the other....

I think any sort of separation at all is counterproductive.  The
existing array/vector split is artificial.  It would be better to have
one array-like type and allow a reasonable set of operations on it.
Target lowering should take care of legality issues.  For best
performance various transformation patterns will want to know about the
target but that's true independent of vector types.  Scalar optimizers
want to know about targets too.

> As far as I am aware not a single one of any of the above types of
> instruction sets allows the "subscripting" of packed data within a
> register

Given what we know of Larrabee and speculating that the "Knights" family
is likely a derivative of it, it's safe to assume that future Intel
architectures will be much more like traditional vector machines.  That
means gather/scatter, element indexing, etc.  The existing PINSR/PEXTR
and shuffle instructions already allow a degree of element indexing.
Note that the existing LLVM vector types already have insert/extract
operators.

Unifying array and vector and generalizing the result would open a lot
of optimization opportunities.

                              -Dave