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

[Snider, Todd via llvm-dev]

Is anyone in the community already looking at extending the implementation of AvailableFunctionAttrs beyond a uint64_t bitmask?

Would a bit vector replacement be an amenable alternative for bitcode encodings of attributes?

The llvm.org guidelines suggest that there should be some delineation between target-independent and target-dependent attributes, but I can't find evidence of this in the way that attributes are represented in the LLVM IR. Am I missing something? Should we be moving attributes in a direction similar to the way that intrinsics are supported in the source base?

~ Todd

-----Original Message-----
From: Doerfert, Johannes [mailto:jdoerfert at anl.gov] 
Sent: Thursday, March 14, 2019 4:04 PM
To: Snider, Todd
Cc: llvm-dev
Subject: [EXTERNAL] Re: [llvm-dev] [RFC] We are running out of slots in the Attribute::AttrKind enum

We should also consider an extension. Maybe using the last bit to indicate a lookup in a second 64-bit mask, or if the memory footprint is not a problem, even a bitvector implementation.


There is certainly interest in adding more attributes (I can provide references if needed), making them faster would certainly not hurt.

Cheers,
  Johannes


On 03/14, Snider, Todd via llvm-dev 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


-- 

Johannes Doerfert
Researcher

Argonne National Laboratory
Lemont, IL 60439, USA

jdoerfert at anl.gov