================
@@ -7095,6 +7096,40 @@ class APValueToBufferConverter {
return true;
}
+ bool visitVector(const APValue &Val, QualType Ty, CharUnits Offset) {
+ const auto *VT = Ty->castAs<VectorType>();
+ unsigned VectorLength = Val.getVectorLength();
+
+ if (VT->isExtVectorBoolType()) {
+ // Special handling for OpenCL bool vectors: we need to pack the vector
+ // of 1-bit unsigned integers into a single integer with the
corresponding
+ // bits set, then write out the resulting integer.
+
+ CharUnits VecWidthBits = Info.Ctx.getTypeSizeInChars(VT) * 8;
+
+ APSInt Bits(VecWidthBits.getQuantity());
+ for (unsigned I = 0; I != VectorLength; ++I) {
+ const APValue &SubObj = Val.getVectorElt(I);
+ assert(SubObj.isInt() && "Bool vector element isn't an int?");
+ Bits.setBitVal(I, !SubObj.getInt().isZero());
----------------
zygoloid wrote:
>From what I've found through some experimentation, it looks like:
- Vector element 0 is always stored at a lower address than vector element 8.
- The actual vector loads and stores operate like integer loads and stores, and
in particular, if the vector is narrower than the storage, you get padding
beyond the high-order bits.
Which I think means that for big-endian systems we want to put vector element
`I` in integer bit `VectorLength - I - 1`, so that when we reverse and
right-align the bits, we end up with the first vector element in the earlier
memory address.
That seems to match what's described in
https://llvm.org/docs/LangRef.html#vector-type
https://github.com/llvm/llvm-project/pull/66894
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
