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

[Meador Inge]

On Nov 26, 2012, at 3:20 PM, Bill Wendling wrote:

>>  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)
>> 
> The problem with this is it limits the number of attribute groups to a specific set -- compile options, non-compile options, etc.. There could be many different attribute groups involved, especially during LTO. I realize that the names will be uniqued. But that just adds a number to the existing name. I also want to avoid partitioning of the attributes into arbitrary groups -- i.e., groups with specific names which imply their usage or type.

My main concern is that I see no reason to limit the id to just numbers in the *language definition*.
That doesn't mean you can't always generate #<number> (in the same way that we do for variable names).
This way it leaves open the possibility of hand-writing nice names.

>>  5. Can attributes be nested?  For example:
>> 
>>        attrgroup #1 = { foo, bar }
>>        attrgroup #2 = { #1, baz }
>> 
>>     Might be nice.
>> 
> I'm not a big fan of this idea. This could open it up to circular attribute groups:
> 
> 	attrgroup #1 = { foo, #2 }
> 	attrgroup #2 = { #1, bar }
> 
> which I'm opposed to on moral groups. ;-) A less compelling (but IMHO valid) argument is that it makes the internal representation of attributes that much more complex.

Fair enough.

>> In other words, I think something like the following might be nicer:
>> 
>> attribute_group := attributes <attrgroup_id> = { <attribute_list> }
>> attrgroup_id    := #<id>
>> attribute_list  := <attribute> ( <attribute>)*
>> attribute       := <name> (= <value>)?
>>                | <attribuge_id>
>> 
>> …
>> 
>> function_def    := <attribute_list> <result_type> @<id> ([argument_list]) <attribute_list>
>> 
> So something like this (no references inside of the 'attributes' statement allowed, cf. above)?
> 
> 	attributes #1 = { noinline, alignstack=4 }
> 	attributes #2 = { "no-sse" }
> 
> 	define void @foo() #1 #2 { ret void }
> 
> This seems reasonable to me.

Me too.  This seem pretty close to what was implemented in the patches posted on
llvm-commits.  I review those in a bit.

--
Meador Inge
CodeSourcery / Mentor Embedded