================
@@ -16009,6 +16010,58 @@ struct PaddingCalculator {
StartBitOffset + StorageSizeInBits});
}
+ void VisitPackedBooleanVector(const VectorType *VTy,
+ uint64_t StartBitOffset) {
+ const uint64_t CharWidth = Ctx.getCharWidth();
+ assert(StartBitOffset % CharWidth == 0 &&
+ "Expected aligned packed boolean vector");
+ assert(VTy->isPackedVectorBoolType(Ctx));
+ const uint64_t OccupiedSizeInBits = VTy->getNumElements();
+
+ if (Ctx.getTargetInfo().isLittleEndian()) {
+ OccuppiedIntervals.push_back(
+ {StartBitOffset, StartBitOffset + OccupiedSizeInBits});
+ return;
+ }
+
+ // The memory layout of packed boolean vectors in big endian mode is
+ // complex.
+ //
+ // If the number of elements < 8, then the occupied bits are contained
+ // within a single byte, but they start from the most significant bit of
+ // that byte.
+ //
+ // Otherwise, the occupied bits span at least one byte. Compared to the
+ // layout in little endian, only the sequence of bytes containing occupied
+ // bits has its order reversed, but the bits within each byte are still
+ // counted from the least significant bit. So if there are fully padding
+ // bytes, they reside at the higher addresses in both endiannesses.
+
+ // Number of elements < 8. Single byte. Count from the MSB.
+ if (OccupiedSizeInBits < CharWidth) {
----------------
vhscampos wrote:
It seems to be a codegen bug in Clang: https://godbolt.org/z/Y5ae6hjn9
In static initialisation, the occupied bits are located in the lower bits. On
the other hand, loads and stores see them as located in the higher bits.
In consistency with the general case, I believe the former must be the right
one, therefore the codegen of loads and stores ought to be wrong.
I will remove this corner case since it looks wrong.
https://github.com/llvm/llvm-project/pull/224033
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
