This patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/BPF/BPFAbstractMemberAccess.cpp | ||
---|---|---|
120 | I cannot convince myself that this is an NFC. Aggregate initialization will initialize RecordAlignment to 0, and there are some cases when RecordAlignment is not set by code (e.g. BPFAbstractMemberAccess::IsPreserveDIAccessIndexCall). On the other hand, the only usage is uint32_t MemberBitSize = MemberTy->getSizeInBits(); uint32_t MemberBitOffset = MemberTy->getOffsetInBits(); uint32_t AlignBits = RecordAlignment * 8; if (RecordAlignment > 8 || MemberBitSize > AlignBits) report_fatal_error("Unsupported field expression for llvm.bpf.preserve.field.info, " "requiring too big alignment"); So it looks like 0 would always lead to a fatal error anyway, so non-zero is really not intended. |
llvm/lib/Target/BPF/BPFAbstractMemberAccess.cpp | ||
---|---|---|
120 | I find this puzzling because the error specifically mentions "llvm.bpf.preserve.field.info" and if you look at IsPreserveDIAccessIndexCall, the only case where RecordAlignment can be 0 is when GV->getName().startswith("llvm.bpf.preserve.field.info"). On all other cases RecordAlignment>0 and GV->getName() would start with one of:
So it doesn't make sense to me. As you said, 0 would lead to a fatal error so I take this as RecordAlignment!=0. |
I cannot convince myself that this is an NFC. Aggregate initialization will initialize RecordAlignment to 0, and there are some cases when RecordAlignment is not set by code (e.g. BPFAbstractMemberAccess::IsPreserveDIAccessIndexCall).
On the other hand, the only usage is
So it looks like 0 would always lead to a fatal error anyway, so non-zero is really not intended.