================
@@ -6901,51 +6916,260 @@ bool HandleOperatorDeleteCall(EvalInfo &Info, const
CallExpr *E) {
//===----------------------------------------------------------------------===//
namespace {
-class BitCastBuffer {
- // FIXME: We're going to need bit-level granularity when we support
- // bit-fields.
- // FIXME: Its possible under the C++ standard for 'char' to not be 8 bits,
but
- // we don't support a host or target where that is the case. Still, we should
- // use a more generic type in case we ever do.
- SmallVector<std::optional<unsigned char>, 32> Bytes;
+struct BitSlice : public std::slice {
+ BitSlice(size_t Offset, size_t Num) : std::slice(Offset, Num, 1){};
- static_assert(std::numeric_limits<unsigned char>::digits >= 8,
- "Need at least 8 bit unsigned char");
+ inline size_t end() const { return start() + size(); }
+};
- bool TargetIsLittleEndian;
+struct BitFieldInfo {
+ /// The offset (in bits) within the appropriate storage type.
+ const unsigned Offset : 16;
+
+ /// The size of the value held by the bit-field, in bits.
+ const unsigned Width : 15;
+
+ /// Whether the bit-field is signed.
+ const unsigned IsSigned : 1;
+
+ /// The storage size in bits which should be used when accessing this
+ /// bitfield.
+ const unsigned StorageSize;
+
+ /// The offset of the bitfield storage from the start of the struct.
+ const CharUnits StorageOffset;
+
+ static BitFieldInfo MakeInfo(const ASTContext &Ctx, const FieldDecl *FD,
+ const ASTRecordLayout &Layout) {
----------------
sethp wrote:
This is part-way to the aforementioned refactoring of the bit-field layout &
access logic between AST and codegen; this `MakeInfo` method happens to make
the same choices that codegen does, but those choices seem very consistent
across time and even compilers (sorry, I lost the godbolt link for this one).
Really it's only two:
1. What happens with "oversized" bit-fields, and
2. What "direction" does the offset count on little-endian vs. big-endian?
At this point, the answers seem consistent; most of the complicated stuff
already got handled in setting up the bit-wise field offsets in the first
place.
That said, at this point I'm a little stuck: I can move logic around between
here, CGRecordBuilder/CGRecordLowering, and `AST/RecordLayoutBuilder.cpp`, but
I don't have a sense of clarity around the outcome I'd be looking for there. I
suspect the goal is shaped something like "someone looking to answer those two
questions differently affects the constant evaluator with their changes", but
I'm not sure how I'd achieve that.
https://github.com/llvm/llvm-project/pull/74775
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
