<p dir="ltr"><br>
On Feb 9, 2013 8:45 AM, "Bill Wendling" <<a href="mailto:wendling@apple.com">wendling@apple.com</a>> wrote:<br>
><br>
> Using the New Attributes Classes</p>
<p dir="ltr">Thanks for writing this up, Bill. Makes a fair bit of sense & should be useful. </p>
<p dir="ltr">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)</p>
<p dir="ltr">> Attributes in LLVM have changed in some fundamental ways. It was necessary to do<br>
> this to support expanding the attributes to encompass more than a handful of<br>
> attributes --- e.g. command line options. The old way of handling attributes<br>
> consisted of representing them as a bit mask of values. This bit mask was stored<br>
> in a "list" structure that was reference counted. The advantage of this was that<br>
> attributes could be manipulated with 'or's and 'and's. The disadvantage of this<br>
> was that there was limited room for expansion, and virtually no support for<br>
> attribute-value pairs other than alignment.<br>
><br>
> In the new scheme, an Attribute object represents a single attribute that's<br>
> uniqued. You use the "Attribute::get" methods to create a new Attribute<br>
> object. An attribute can be a single "enum" value (the enum being the<br>
> Attribute::AttrKind enum), a string representing a target-dependent attribute,<br>
> or an attribute-value pair. Some examples:<br>
><br>
> Target-independent: noinline, zext<br>
> Target-dependent: "no-sse", "thumb2"<br>
> Attribute-value pair: "cpu" = "cortex-a8", align = 4<br>
><br>
> (Note: for an attribute value pair, we expect a target-dependent attribute to<br>
> have a string for the value.)<br>
><br>
> An Attribute object is designed to be passed around by value.<br>
><br>
> Because attributes are no longer represented as a bit mask, you will need to<br>
> convert any code which does treat them as a bit mask to use the new query<br>
> methods on the Attribute class. This should be straight forward. If there is<br>
> missing functionality on the Attribute class, which you feel should be there,<br>
> please let me know about it.<br>
><br>
> The next class is the AttributeSet class. This replaces the old AttributeList<br>
> class. The AttributeSet stores a collection of Attribute objects for each kind<br>
> of object that may have an attribute associated with it: the function as a<br>
> whole, the return type, or the function's parameters. A function's attributes<br>
> are at index "AttributeSet::FunctionIndex"; the return type's attributes are at<br>
> index "AttributeSet::ReturnIndex"; and the function's parameters' attributes are<br>
> at indices 1, ..., n (where 'n' is the number of parameters). Most methods on<br>
> the AttributeSet class take an index parameter.</p>
<p dir="ltr">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<AttributeSet>? (Or even attaching the respective AttributeSets to the various pieces (parameters/return type etc) - though I expect that might not work as well/easily)</p>
<p dir="ltr">> An AttributeSet is also a uniqued and immutable object. You create an<br>
> AttributeSet through the "AttributeSet::get" methods. You can add and remove<br>
> attributes, which result in the creation of a new AttributeSet.<br>
><br>
> An AttributeSet object is designed to be passed around by value.<br>
><br>
> Note: It is advised that you do *not* use the AttributeSet "Introspection"<br>
> methods (e.g. 'Raw', 'getRawPointer', etc.). These methods break encapsulation,<br>
> and may be removed in a future release (i.e. 4.0).<br>
><br>
> Lastly, we have a 'builder' class to help create the AttributeSet object without<br>
> having to create several different intermediate uniqued AttributeSet<br>
> objects. The AttrBuilder class allows you to add and remove attributes at<br>
> will. The attributes won't be uniqued until you call the appropriate<br>
> "AttributeSet::get" method.<br>
><br>
> An AttrBuilder object is *not* designed to be passed around by value. It should<br>
> be passed by reference.<br>
><br>
> Note: It is advised that you do *not* use the "AttrBuilder::addRawValue()"<br>
> method or the "AttrBuilder(uint64_t Val)" c'tor. These are for backwards<br>
> compatibility and may be removed in a future release (i.e. 4.0).<br>
><br>
> And that's basically it! A lot of functionality is hidden behind these classes,<br>
> but the interfaces are pretty straight forward. Please let me know if you have<br>
> any questions about how to use these classes, or if there is any functionality<br>
> you feel is missing.<br>
><br>
> -bw<br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</p>