[llvm-dev] [RFC] We are running out of slots in the Attribute::AttrKind enum

[Reid Kleckner via llvm-dev]

Why aren't string attributes appropriate for your use case? Why do you need
the attribute to be a recognized enum?

I cannot find any references to CMSE_NS_CALL anywhere in trunk LLVM. The
only result google gave for me for it was:
https://www.iar.com/globalassets/about-us/events/ew2019/ew2019-working-effectively-with-trustzone-devices.pdf

I looked at the latest code for writing bitcode, and I don't think it uses
a bitmask to store enum attributes anymore. See this code:
https://github.com/llvm-git-prototype/llvm/blob/a845b0985672ee66c1cc8e070ca5d5ac6e89c0c9/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp#L728

So, I don't think there are any compatibility issues with adding more
attributes.

In your next message, you mention AvailableFunctionAttrs, and I think all
that needs to be done is to rewrite it to use std::bitset, as is done in
AttrBuilder.

On Thu, Mar 14, 2019 at 1:20 PM Snider, Todd via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I would like to add a target-dependent attribute to the LLVM IR, and the
> guidance in http://llvm.org/docs/HowToUseAttributes.html says that
> target-dependent attributes should not occupy a slot in the
> Attribute::AttrKind enum, but I have yet to find an attribute that is
> represented in the IR that does not also have a slot in the AttrKind enum.
>
>
>
> We are limited to 63 slots in the AttrKind enum because it is represented
> in the bitcode with a 64-bit bitmask. There is only one free slot left and
> I don’t want to use it for a target-dependent attribute. I had anticipated
> that only target-independent attributes would have analogous ATTR_KIND
> identifiers in the AtttrKind enum, yet the ARM-specific CMSE_NS_CALL and
> CMSE_NS_ENTRY occupy slots in the AttrKind enum.
>
>
>
> Can someone point me to an example of a target-dependent attribute
> represented in the LLVM IR that does not occupy a slot in the AttrKind enum?
>
>
>
> Thanks,
>
>
>
> Todd Snider
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190315/dc154a88/attachment-0001.html>