Reid, thanks for the response. I think I now have a path forward for adding target-dependent attributes as string attributes instead of enum attributes.
For informational purposes, after digging deeper into how the bitcode reader and writer work for enum attributes, I conclude:
· Attributes are encoded in the bitcode file as groups
· Each enum attribute within a group is identified by its encoding value which matches the value is was given in the AttrKind enum specification (i.e. its ATTR_KIND_xxx value)
· BitcodeWriter handling of enum attributes:
o The bitcode writer has an EnumAttributeImpl version of the attribute kind which you can get from Attr.getKindAsEnum(); I believe this is the index into the Attribute specification table that gets generated from Attributes.td when llvm/clang is built
o Calling getAttrKindEncoding(x) where x is Attr.getKindAsEnum() will then present the encoding value that goes into the bitcode file to identify the attribute kind
o There is not a limitation on the size of the AttrKind enum. However, there is a static assert (~line 820+ - AttributeListImpl()) that enforces that the number of slots occupied in the AttrKind enum is less than (sizeof(AvailableFunctionAttrs) * CHAR_BITS). Since AvailableFunctionAttrs currently has type uint64_t, this static assert needs to be updated or removed (it is currently incorrectly limiting the enum to 64 slots – including the Attribute::none slot).
· BitcodeReader handling of enum attributes:
o The reader no longer uses the getRawAttributeMask() or addRawAttributeValue() functions. I had incorrectly assumed that they were still in play.
o The reader uses getAttrFromCode() to map the encoded value of the attribute to the Attribute specification index (i.e. ATTR_KIND_xxx → Attribute::xxx)
The reason I became concerned about running out of slots in the AttrKind enum is because my work group has a couple of target-independent attributes that we will be looking to upstream in the near future. When I attempted to merge changes from the upstream repo into our local source base (that contains an implementation of those attributes), the static assert mentioned above prevented a successful build.
I propose to update or remove the above static assert so that it correctly reflects the current state of the bitcode reader/writer with respect to enum attributes.
Does that make sense?
~ Todd Snider