================
@@ -7304,6 +7382,21 @@ class BufferToAPValueConverter {
return ArrayValue;
}
+ std::optional<APValue> visit(const VectorType *Ty, CharUnits Offset) {
+ SmallVector<uint8_t, 8> Bytes;
+ if (!Buffer.readObject(Offset, Info.Ctx.getTypeSizeInChars(Ty), Bytes))
+ return std::nullopt;
----------------
DaMatrix wrote:
Hrm, this is indeed awkward: I obviously can't load the entire f80 vector at
once, but loading individual elements at a time would not only force me to
duplicate much of the code again, but would also make bool vectors break again
without once again adding special handling (since we'd have to load individual
bytes at a time again).
Can we simply assume the uninitialized padding bits are always zero? This test
in `CodeGen/const-init.c` (the case `b`):
https://github.com/llvm/llvm-project/blob/8768741800aae37a825864e2ee782484ed073ce9/clang/test/CodeGen/const-init.c#L138-L148
which uses `CK_BitCast` seems to make that assumption, while a variety of the
existing tests in `SemaCXX/constexpr-builtin-bit-cast.cpp`:
https://github.com/llvm/llvm-project/blob/8768741800aae37a825864e2ee782484ed073ce9/clang/test/SemaCXX/constexpr-builtin-bit-cast.cpp#L332-L351
assume that bit-casting padding space should return uninitialized values (or
fail when the target type isn't allowed to be uninitialized in a constexpr
context).
Is the `CK_BitCast` assumption simply wrong, or do these two different ways of
triggering a bit cast really have such different semantics? I can see a few
places in the actual LLVM constant folding code where vector bit casts
containing uninitialized elements are, in fact, initialized to zero, but I feel
like that makes sense there since it doesn't have to adhere to the rules of
`constexpr`. Should I rewrite all the bit cast conversion code in
`APValueToBufferConverter`/`BufferToAPValueConverter` again while taking
uninitialized padding bytes into account, and redirect the existing
`CK_BitCast` code to point to that?
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
