[LLVMdev] vectors of pointers (why not?)

[Matt Pharr]

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