llvm dev - Feb 2011 - [LLVMdev] vectors of pointers (why not?)

I'm writing a compiler where I'd like to be able to (sometimes)
represent lvalues of vectors (e.g. <4xfloat>) with vectors of pointers
(e.g. <4xfloat *>).  In this case, I'd like to be generating these
vectors of pointers early on and later converting operations on them to a series
of individual loads/stores with a later pass.  (Note, though, that ISAs with
"gather"/"scatter" instructions could do interesting
operations on vectors of pointers directly...)

However, llvm disallows vectors of pointers.  llvm 2.8 would issue an error if
it found any when running the module verifier pass; I had previously worked
around this by creating vectors of i64s in cases where I actually wanted a
vector of pointers, doing individual PtrToInt / IntToPtr conversions on the way
in and out.  Alongside this, I carried along an llvm::Type of the desired
pointer type (e.g. <4xfloat *>), so that I could bitcast appropriately on
the way back out.  This was a hack, but it worked, though it also was wasteful
for targets with 32-bit pointers.

Unfortunately, llvm TOT now seems to prohibit even constructing a Type
representing a vector of pointers, firing on an assertion in a constructor.

My question is, why these prohibitions? I'd be a big help to have even a
small loosening of restrictions that, say, allowed vectors of pointers but
basically didn't allow any operations other than
insertelement/extractelement on them.  (I wouldn't complain about allowing
more operations on them, e.g. a vectorized GEP instruction that took a vector of
pointers and vectors of offsets, or load/store instructions that took them and
turned them into individual loads/stores, but those are bigger changes!)

I realize I could disable these assertions in my own llvm tree, but a) I'd
like to know whether those assertions are there to enforce the specified
restrictions or whether they are there to prevent bad things from happening
downstream, and b) if the change is possible, it'd be nice to have it in the
general distribution.

Thanks for any help/guidance.

-matt
-- 
Matt Pharr
http://pharr.org/matt

On 02/08/2011 05:12 PM, Matt Pharr wrote:
> I'm writing a compiler where I'd like to be able to (sometimes)
represent lvalues of vectors (e.g.<4xfloat>) with vectors of pointers
(e.g.<4xfloat *>).  In this case, I'd like to be generating these
vectors of pointers early on and later converting operations on them to a series
of individual loads/stores with a later pass.  (Note, though, that ISAs with
"gather"/"scatter" instructions could do interesting
operations on vectors of pointers directly...)
>
> However, llvm disallows vectors of pointers.  llvm 2.8 would issue an error
if it found any when running the module verifier pass; I had previously worked
around this by creating vectors of i64s in cases where I actually wanted a
vector of pointers, doing individual PtrToInt / IntToPtr conversions on the way
in and out.  Alongside this, I carried along an llvm::Type of the desired
pointer type (e.g.<4xfloat *>), so that I could bitcast appropriately on
the way back out.  This was a hack, but it worked, though it also was wasteful
for targets with 32-bit pointers.
>
> Unfortunately, llvm TOT now seems to prohibit even constructing a Type
representing a vector of pointers, firing on an assertion in a constructor.
>
> My question is, why these prohibitions? I'd be a big help to have even
a small loosening of restrictions that, say, allowed vectors of pointers but
basically didn't allow any operations other than
insertelement/extractelement on them.  (I wouldn't complain about allowing
more operations on them, e.g. a vectorized GEP instruction that took a vector of
pointers and vectors of offsets, or load/store instructions that took them and
turned them into individual loads/stores, but those are bigger changes!)
>
> I realize I could disable these assertions in my own llvm tree, but a)
I'd like to know whether those assertions are there to enforce the specified
restrictions or whether they are there to prevent bad things from happening
downstream, and b) if the change is possible, it'd be nice to have it in the
general distribution.
>
> Thanks for any help/guidance.
>
> -matt

Could you use an array of pointers instead? As far as I'm aware, the 
vector types in LLVM are intended to abstract the vector units on modern 
CPUs (SSE, etc.) which generally support operations on only integers and 
floating point values, which may be why there isn't native support for 
vectors of pointers.

Andrew

Andrew Clinton <andrew at sidefx.com> writes:
> Could you use an array of pointers instead? As far as I'm aware, the 
> vector types in LLVM are intended to abstract the vector units on modern 
> CPUs (SSE, etc.) which generally support operations on only integers and 
> floating point values, which may be why there isn't native support for 
> vectors of pointers.
Except that modern processors are far more expressive than SSE.  Knights
Ferry has gather/scatter instructions.  Now I know Knights Ferry isn't a
supported target and probably won't be for a while, if ever, but
something that looks like it is almost certainly going to go mainstream
in the next 2-3 years.

It's certainly worth seriously considering how LLVM will support more
traditional vector-style ISAs in the near future.

                                    -Dave