64-bit Attributes?

Hi,

Today, llvm/Attributes.h defines ‘Attributes’ as ‘unsigned’.
This bit vector is fully packed, and I am probably not the only one who wants to add bits to it.
Is there a strong reason not to define Attributes as uint64_t?
At first glance this seems doable, and the IR reader/writer will not need to be changed at all (or at least, not significantly).

Thanks,

–kcc

Hi Kostya,

Today, llvm/Attributes.h defines 'Attributes' as 'unsigned'.
This bit vector is fully packed, and I am probably not the only one who wants to
add bits to it.
Is there a strong reason not to define Attributes as uint64_t?
At first glance this seems doable, and the IR reader/writer will not need to be
changed at all (or at least, not significantly).

probably attributes should become a (pointer to) a more complicated data
structure. For example, I would like to get rid of the zext/sext parameter
attributes and replace with "z/sexted_from(type)" where type is an arbitrary
integer type. This will never fit into 64 bits. Maybe now is the time to
think of a more powerful representation for attributes.

Ciao, Duncan.

Hi Kostya,

Today, llvm/Attributes.h defines ‘Attributes’ as ‘unsigned’.
This bit vector is fully packed, and I am probably not the only one who wants to
add bits to it.
Is there a strong reason not to define Attributes as uint64_t?
At first glance this seems doable, and the IR reader/writer will not need to be
changed at all (or at least, not significantly).

probably attributes should become a (pointer to) a more complicated data
structure.

that would be a bigger change…
Does anyone else feel such need?
(I need just one extra bit for AddressSanitizer/SAFEcode :))

For example, I would like to get rid of the zext/sext parameter
attributes and replace with “z/sexted_from(type)” where type is an arbitrary
integer type.

You mean, other than i8/i16/i32/i64?

–kcc