[LLVMdev] [RFC] Attributes Rewrite (Final)

[Chris Lattner]

On Jan 29, 2013, at 2:42 PM, Bill Wendling <isanbard at gmail.com> wrote:
> Executive Summary:
> 
> The new syntax is:
> 
> 	#0 = attributes { noinline align=4 "cpu"="cortex-a8" }
> 	#1 = attributes { attr = (val1 val2 val3) }
> 	#bork = attributes { sspreq noredzone }
> 
> 	define void @foo() #0 #bork { ret void }

The general syntax LGTM.  It seems clean and fits well with what we have.

> The 'align' and "cpu" attributes both have a value associated with them. The 'attr' attribute in '#1' has multiple values associated with it. (The BNF is below in the 'IR Changes' section.) Attribute groups with the same attributes in them, but in a different order, are identical. So '@bar' and '@qux' have the same attributes in this example:

What is the use case for the multi-value attribute?  Perhaps obvious, but it makes sense to stage this out to add one thing at a time.  Also, your BNF doesn't make it clear what is allowed for <value>: I would assume it is a set of hardcoded keywords (like align, sspreq, etc) plus the string form.  If so, how does "val1" fit into that?

> Proposal
> ========
> 
> We will expand the Attriutes class to support all of the attributes that the
> compiler may care about. Anything that affects code transformations and code
> generation will be specified inside of the Attributes class. This allows for a
> cleaner interface for the front-ends, since they won't have to fill in a
> target-specific structure to pass along this information.

It will also hopefully allow us to eliminate most or all of the "global" variables crammed into the TargetOptions class.

> There are two classes of attributes: those that are target-independent (e.g.,
> 'noinline'), and those that are target-dependent (e.g., 'thumb' and
> 'cpu=cortex-a8'). The target-dependent options are stored as strings inside of
> the Attributes class. The target's back-end is responsible for interpreting
> target-dependent attributes.
> 
> Attributes should be documented in the language reference document.

Target specific attributes should probably be listed in the target-specific section of docs/CodeGenerator.rst.

> The core of this proposal is the idea of an "attribute group". As the name
> implies, it's a group of attributes that are then referenced by objects within
> the IR. An attribute group is a module-level object. The BNF of the syntax is:
> 
>  attribute_group := <attrgroup_id> '=' attributes '{' <attribute_list> '}'
>  attrgroup_id    := #<id>
>  attribute_list  := <attribute> <attribute>*
>  attribute       := <name> ('=' <list_of_values>)?
>  list_of_values  := <value> | '(' <value> <value>* ')'
>  id              := <number> | <name>

As mentioned above, it is unclear what "value" is.  It makes sense to me to make it one of a hard-coded list of well-known stuff we know about (like align) plus double-quoted strings, used for target-specific stuff.

> Attribute groups are important for keeping `.ll' files readable, because a lot
> of functions will use the same attributes. In the degenerative case of a `.ll'
> file that corresponds to a single `.c' file, the single `attrgroup' will capture
> the command line flags used to build that file.

It's worth noting that the structure of attribute groups is an .ll file syntax thing, they aren't reflected in the IR once parsed.

> 
> Target-Dependent Attributes in IR
> ---------------------------------
> 
> The front-end is responsible for knowing which target-dependent options are 
> interesting to the target. Target-dependent attributes are specified as strings,
> which are understood by the target's back-end. E.g.:
> 
> 	#0 = attributes { "long-calls", "cpu=cortex-a8", "thumb" }

"cpu=cortex-a8" or "cpu"="cortex-a8"?

-Chris