We are going to add a function attribute number 64.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
I've moved the bitset into the padding of NumAttrSets so hopefully this will not waste any memory.
Thanks for working on this. Making sure we can extend attributes is a bit of a hassle now that we reached the magic number ;)
This looks fine to me but I'm not to involved in these parts. Let's see if someone else want to approve this.
We are going to add a function attribute number 64.
Out of curiosity, which one do you mean here?
It's sanitize_memtag in the child revision.
Actually, we were fine without this until your change on Jule 10 pushed our pending attribute over the limit :)
llvm/lib/IR/AttributeImpl.h | ||
---|---|---|
250 ↗ | (On Diff #209572) | std::bitset? |
It seems it's my fault...
(sorry for derailing this, always wanted to try these memes they added)
llvm/lib/IR/AttributeImpl.h | ||
---|---|---|
250 ↗ | (On Diff #209572) | We also have a llvm::SmallBitVector. If we keep a fixed size encoding we should add a (static) assert so it'll break in a informative manner once the new limit is reached. |
std::bitset is word-aligned at least in libc++ implementation, so it would waste 4 bytes here.
SmallBitVector has only 64 bits of inline storage.
I would prefer to keep this the way it is with an array so that it is obvious what the size/alignment are.
It would be good to have a static assertion of some sort, though. It looks like Attribute::EndAttrKinds could be used for this purpose.
Ah, I missed that.
LGTM
llvm/lib/IR/AttributeImpl.h | ||
---|---|---|
250 ↗ | (On Diff #209572) | Nit: maybe do uint8_t AvailableFunctionAttrs[12] = {}; to avoid needing to put the initializer in the ctor. |
Tested by adding a bunch of fake attributes at the beginning to push the interesting ones out of 0..64 range, and also with ASan.