[LLVMdev] [RFC] Passing Options to Different Parts of the Compiler Using Attributes

[Bill Wendling]

On Nov 20, 2012, at 4:31 PM, Richard Smith <richard at metafoo.co.uk> wrote:

> On Tue, Nov 20, 2012 at 11:03 AM, Meador Inge <meadori at codesourcery.com> wrote:
>> 
>> On Nov 13, 2012, at 12:20 AM, Bill Wendling wrote:
>> 
>>> IR Changes
>>> ----------
>>> 
>>> The attributes will be specified within the IR. This allows us to generate code
>>> that the user wants. This also has the advantage that it will no longer be
>>> necessary to specify all of the command line options when compiling the bit code
>>> (via 'llc' or 'clang'). E.g., '-mcpu=cortex-a8' will be an attribute and won't
>>> be required on llc's command line. However, explicit flags (like `-mcpu') on the
>>> llc command line will override flags specified in the module.
>>> 
>>> 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 <attrgroup_id> = { <attribute_list> }
>>> attrgroup_id    := #<number>
>>> attribute_list  := <attribute> (, <attribute>)*
>>> attribute       := <name> (= <value>)?
>>> 
>>> To use an attribute group, an object references the attribute group's ID:
>>> 
>>> attribute_group_ref := attrgroup(<attrgroup_id>)
>>> 
>>> This is an example of an attribute group for a function that should always be
>>> inlined, has stack alignment of 4, and doesn't unwind:
>>> 
>>> attrgroup #1 = { alwaysinline, nounwind, alignstack=4 }
>>> 
>>> void @foo() attrgroup(#1) { ret void }
>>> 
>>> An object may refer to more than one attribute group. In that situation, the
>>> attributes are merged.
>>> 
>>> 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.
>> 
>> A few comments on the new syntax:
>> 
>>   1. I think most folks will understand what 'attrgroup' means, but it is a little cryptic.
>>      How about just 'attributes'?  The following reads easier to my eyes:
>> 
>>         attributes #1 = { alwaysinline, nounwind, alignstack=4 }
>>         void @foo() attributes(#1) { ret void }
>> 
>>   2. Are group references allowed in all attribute contexts (parameter, return value, function)?
>>      I think the answer should be yes.  Also, it might be worth considering using the same attribute
>>      list syntax in the current context and the new attribute group definition (i.e. comma-separated
>>      v.s. space-separated).  This way we have a consistent syntax for groups of attributes and the
>>      main addition this proposal adds is to give a name to those attributes for later reference.
>> 
>>   3. Can attribute groups and single attributes be inter-mixed?
>>      For example:
>> 
>>         void @foo attrgroup(#1) alwaysinline attrgroup(#2) nounwind
>> 
>>   4. Do we really want the attribute references limited to a number?  Code will be more readable
>>      if you can use actual names that indicate the intent.  For example:
>> 
>>         attrgroup #compile_options = { … }
>>         void @foo attrgroup(#compile_options)
>> 
>>   5. Can attributes be nested?  For example:
>> 
>>         attrgroup #1 = { foo, bar }
>>         attrgroup #2 = { #1, baz }
>> 
>>      Might be nice.
>> 
>>   6. Do we really need to specify the attrgroup keyword twice? (Once in the group definition and once in the use)
>>      ISTM, that the hash-mark is enough to announce a group reference in the use.  For example:
>> 
>>         void @foo #1 alwaysinline #2 no unwind
>> 
>> In other words, I think something like the following might be nicer:
>> 
>> attribute_group := attributes <attrgroup_id> = { <attribute_list> }
> 
> Well, if we're picking paints for this bikeshed, are the braces here
> necessary? We don't have braces for the other places we have
> <attribute_list>s.
> 
> attributes #attrs = nounwind alwaysinline noreturn
> i8 @foo() #attrs
> 
> ... as a synonym for ...
> 
> i8 @foo() nounwind alwaysinline noreturn
> 
> ... seems quite clean to me.
> 

I prefer them, because it makes it clearer (to me) which attributes are added to the group. It's possible that the list could get long.

-bw