[clang] [clang] Implement constexpr bit_cast for vectors (PR #66894)

[Richard Smith via cfe-commits]

================
@@ -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