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. > > -mattCould 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