[LLVMdev] [RFC] Attributes Rewrite (Final)

[Bill Wending]

On Feb 3, 2013, at 10:45 AM, Chris Lattner <clattner at apple.com> wrote:

> 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.
> 
Thanks! :-)

>> 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?
> 
I added it because I wanted to limit possible future changes to the IR. But that may be premature. It would essentially act like the '-mattr' command line option works today. Of course the -mattr functionality is covered by this proposal. I will omit that part and leave it for a future expansions if necessary. It won't be a major change to the IR at that point.

My first thoughts about what <value> can be is something that can be represented by a Constant object. So a keyword, string, or numerical value. I expect string values to be used mainly for target-dependent attributes. The other two forms would be used for target-independent attributes defined in the LangRef.

>> 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.
> 
God-willing, yes! :-)

>> 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.
> 
Okay, that makes sense. 

>> 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.
> 
That sounds reasonable.

>> 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.
> 
Yes. In particular, we won't be trying to preserve the .ll syntax when it's run through llvm-as and llvm-dis.

>> 
>> 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"?

The latter.

-bw