Using the New Attributes Classes

Using the New Attributes Classes

Attributes in LLVM have changed in some fundamental ways. It was necessary to do
this to support expanding the attributes to encompass more than a handful of
attributes --- e.g. command line options. The old way of handling attributes
consisted of representing them as a bit mask of values. This bit mask was stored
in a "list" structure that was reference counted. The advantage of this was that
attributes could be manipulated with 'or's and 'and's. The disadvantage of this
was that there was limited room for expansion, and virtually no support for
attribute-value pairs other than alignment.

In the new scheme, an Attribute object represents a single attribute that's
uniqued. You use the "Attribute::get" methods to create a new Attribute
object. An attribute can be a single "enum" value (the enum being the
Attribute::AttrKind enum), a string representing a target-dependent attribute,
or an attribute-value pair. Some examples:

   Target-independent: noinline, zext
   Target-dependent: "no-sse", "thumb2"
   Attribute-value pair: "cpu" = "cortex-a8", align = 4

(Note: for an attribute value pair, we expect a target-dependent attribute to
have a string for the value.)

An Attribute object is designed to be passed around by value.

Because attributes are no longer represented as a bit mask, you will need to
convert any code which does treat them as a bit mask to use the new query
methods on the Attribute class. This should be straight forward. If there is
missing functionality on the Attribute class, which you feel should be there,
please let me know about it.

The next class is the AttributeSet class. This replaces the old AttributeList
class. The AttributeSet stores a collection of Attribute objects for each kind
of object that may have an attribute associated with it: the function as a
whole, the return type, or the function's parameters. A function's attributes
are at index "AttributeSet::FunctionIndex"; the return type's attributes are at
index "AttributeSet::ReturnIndex"; and the function's parameters' attributes are
at indices 1, ..., n (where 'n' is the number of parameters). Most methods on
the AttributeSet class take an index parameter.

An AttributeSet is also a uniqued and immutable object. You create an
AttributeSet through the "AttributeSet::get" methods. You can add and remove
attributes, which result in the creation of a new AttributeSet.

An AttributeSet object is designed to be passed around by value.

Note: It is advised that you do *not* use the AttributeSet "Introspection"
methods (e.g. 'Raw', 'getRawPointer', etc.). These methods break encapsulation,
and may be removed in a future release (i.e. 4.0).

Lastly, we have a 'builder' class to help create the AttributeSet object without
having to create several different intermediate uniqued AttributeSet
objects. The AttrBuilder class allows you to add and remove attributes at
will. The attributes won't be uniqued until you call the appropriate
"AttributeSet::get" method.

An AttrBuilder object is *not* designed to be passed around by value. It should
be passed by reference.

Note: It is advised that you do *not* use the "AttrBuilder::addRawValue()"
method or the "AttrBuilder(uint64_t Val)" c'tor. These are for backwards
compatibility and may be removed in a future release (i.e. 4.0).

And that's basically it! A lot of functionality is hidden behind these classes,
but the interfaces are pretty straight forward. Please let me know if you have
any questions about how to use these classes, or if there is any functionality
you feel is missing.

-bw

Very nice!

Could we get this write-up added to the sphinx docs?

Using the New Attributes Classes

Thanks for writing this up, Bill. Makes a fair bit of sense & should be useful.

I have a few questions/comments but I’m not suggesting anything should be changed (even if my ideas were solid, which I’ve no reason to believe they are, I’m not really a stakeholder in this part of LLVM)

Attributes in LLVM have changed in some fundamental ways. It was necessary to do
this to support expanding the attributes to encompass more than a handful of
attributes — e.g. command line options. The old way of handling attributes
consisted of representing them as a bit mask of values. This bit mask was stored
in a “list” structure that was reference counted. The advantage of this was that
attributes could be manipulated with 'or’s and 'and’s. The disadvantage of this
was that there was limited room for expansion, and virtually no support for
attribute-value pairs other than alignment.

In the new scheme, an Attribute object represents a single attribute that’s
uniqued. You use the “Attribute::get” methods to create a new Attribute
object. An attribute can be a single “enum” value (the enum being the
Attribute::AttrKind enum), a string representing a target-dependent attribute,
or an attribute-value pair. Some examples:

Target-independent: noinline, zext
Target-dependent: “no-sse”, “thumb2”
Attribute-value pair: “cpu” = “cortex-a8”, align = 4

(Note: for an attribute value pair, we expect a target-dependent attribute to
have a string for the value.)

An Attribute object is designed to be passed around by value.

Because attributes are no longer represented as a bit mask, you will need to
convert any code which does treat them as a bit mask to use the new query
methods on the Attribute class. This should be straight forward. If there is
missing functionality on the Attribute class, which you feel should be there,
please let me know about it.

The next class is the AttributeSet class. This replaces the old AttributeList
class. The AttributeSet stores a collection of Attribute objects for each kind
of object that may have an attribute associated with it: the function as a
whole, the return type, or the function’s parameters. A function’s attributes
are at index “AttributeSet::FunctionIndex”; the return type’s attributes are at
index “AttributeSet::ReturnIndex”; and the function’s parameters’ attributes are
at indices 1, …, n (where ‘n’ is the number of parameters). Most methods on
the AttributeSet class take an index parameter.

This seems like a slightly curious factoring: AttributeSet is actually a list of sets of attributes, yes? Why does the list end up encapsulated within this abstraction rather than something more like vector? (Or even attaching the respective AttributeSets to the various pieces (parameters/return type etc) - though I expect that might not work as well/easily)

The attached patch creates a skeleton to expand Attributes documentation in the future. It is currently only linked to the index.

Ok to commit?

Joe

AttributesDoc.patch (4.25 KB)

ATT00001.htm (5.84 KB)

This looks like a good starting point. I would prefer to call it HowToUseAttributes.rst though (it is essentially a HowTo).

Bill, is it ok to commit this, or would you like cook up something different to go into the docs?

– Sean Silva

Hi Sean,

I think it can go in as it is. It's a good start.

Thanks, Joe!

-bw

Cool I renamed it, per Sean’s suggestion, to HowToUseAttributes.

Committed as r174961

The doc should be live now: http://llvm.org/docs/HowToUseAttributes.html

Cheers,

Joe Abbey

Great! Thanks. :slight_smile:

-bw