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