<div dir="ltr">I've tested it on MSVC, gcc, clang and icc.<div><br></div><div>The solution in clang (in Decl.h) is not ideal (as you have said yourself). The solution I offer, is using a union of fields of class BitField (this is a new class that implements a bitfield of a specific type requested). With this, the definition, of the required bitfields in the subclass data, remains in the hands of the actual class needing them. And these are all restricted hierarchically by the superclasses of that class.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 26, 2019 at 10:22 PM Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">First, please test your technique with MSVC on godbolt. If you change the type (bool a : 1; int b : 2;), it will not pack them into the same bitfield.<div><br></div><div>Second, do we really need macros to do this? See the techniques used in clang::VarDecl:</div><div><a href="https://github.com/llvm/llvm-project/blob/f20fc65887e2085332d111ee0b05736794423c72/clang/include/clang/AST/Decl.h#L878" target="_blank">https://github.com/llvm/llvm-project/blob/f20fc65887e2085332d111ee0b05736794423c72/clang/include/clang/AST/Decl.h#L878</a><br></div><div>As written with a union between all the bitfields, the base class ends up knowing everything about the derived classes, which is not ideal. But, you could imagine a version of this that uses aligned char storage so that subclasses could reinterpret_cast the subclass data memory and use it for their version of subclass data.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 23, 2019 at 11:16 PM Ehud Katz via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello devs,<br><br>Recently I've been working on a bug that can probably be fixed with the addition of a simple flag to a class descendant of `llvm::Value`.<br>Without increasing the size of the class, I can just add this flag to `llvm::Value::SubclassData`. But this is not an easy task!<br><br>This is because the offsetes/sizes of the data stored in the `SubclassData`, are hardcoded literals/enums.<br>If you change but a single bit in one of those offsets/sizes in a base class, then all the classes derived, will have to be adjusted accordingly - which can be very tedious and error-prone.<br><br>I offer a small set of macros which will take care of the whole Subclass-Data.<br>It will work as follows:<br><br>struct A {<br>  int SubclassData : 14;<br>  <br>  DEFINE_SUBCLASS_DATA()<br>};<br><br>struct B : A {<br>  BEGIN_SUBCLASS_DATA()<br>    ADD_SUBCLASS_BITFIELD(int,   5, B1) // A::SubclassData bits [0,5)<br>    ADD_SUBCLASS_BITFIELD(bool,  1, B2) // A::SubclassData bits [5,6)<br>    ADD_SUBCLASS_BITFIELD(short, 6, B3) // A::SubclassData bits [6,12)<br> // ADD_SUBCLASS_BITFIELD(int,   6, B4) // A::SubclassData bits [12,18) - triggers a static_assert, as it exceeds the 14 bits in A::SubclassData<br>    END_SUBCLASS_DATA()<br>};<br><br>struct C : B {<br>  BEGIN_SUBCLASS_DATA()<br>    ADD_SUBCLASS_BITFIELD(bool, 1, C1) // A::SubclassData bits [12,13)<br>    END_SUBCLASS_DATA()<br>};<br><br><br>I would appreciate your thoughts on the matter, before I submit a patch for review.<br><br>Cheers,<br>Ehud.<br></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>