I was re-reading the specification for extractelement and friends, and I
notice that the index is restricted to i32. Since vectors might clearly
have a larger number of elements on 64-bit platforms, I wonder if I am
misunderstanding the intended use of these instructions.
Is this indeed intended for vector and structure access in general, or
is intended to support (only) more specialized SIMD usage?
My real reason for asking is that we would like to remove the "Word"
type (basically: uintptr_t) from the BitC language core, but we
currently specify arrays and vectors as indexed by Word. If we can get
away with specifying the same core type for indices (probably int64) on
all targets without a bad efficiency compromise, I would like to do
that, so I'm trying to understand how LLVM handles this issue.
Thanks
shap
They are intended for SIMD usage. You will get very poor performance if you try to use extremely large vectors with LLVM. Use arrays instead.
-Chris
The code generator cannot handle vectors with more than 16383 (?)
elements. Even so, I'm not sure it makes much sense to use vectors
with more than a handful of elements.
Ciao,
Duncan.
I understood Chris to say that these instructions were for SIMD
machines, and if the limit you mention applies to SIMD I'm not worried.
Does that limit also apply to arrays?
shap
> The code generator cannot handle vectors with more than 16383 (?)
> elements. Even so, I'm not sure it makes much sense to use vectors
> with more than a handful of elements.
I understood Chris to say that these instructions were for SIMD
machines, and if the limit you mention applies to SIMD I'm not worried.
Does that limit also apply to arrays?
No it doesn't, it is vector specific. There may be limits on arrays, but
I don't know what they are.
Ciao,
Duncan.
Arrays can be up to 2^63 in size if I recall.
-Chris