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

[Bill Wendling]

On Nov 13, 2012, at 7:43 AM, Justin Holewinski <justin.holewinski at gmail.com> wrote:

> Couple of quick questions:
> 
> First, what are the valid types for <value>?  Are they always strings which the target must interpret, or will numeric literals and booleans also be supported?

We should be able to support all types of values: strings, integers, boolean, etc.

> Also, in the proposal, attributes are sometimes quoted and sometimes they are not.  I know this is nit-picking, but what is the preferred syntax?

I made a distinction (perhaps artificial) between target independent and target dependent attributes. The independent ones need no quotes while the dependent ones do. This reflects how they are stored and accessed via the Attributes class. I said "perhaps artificial" because there's no real reason why the target dependent options cannot be specified via the attributes enum in the Attributes class. Except, perhaps, to avoid placing target dependent cruft in a general class. :) I'm open to arguments against the original design.

> Second, would it make sense to fold the calling convention into this set of attributes?  For correctness, attributes cannot be stripped from the IR anyway (as I understand it).  The existing calling convention API could be implemented using the new attributes.  The old way of specifying calling conventions (before the function name instead of after) would need to be supported until the next break in IR compatibility, but this doesn't seem like a big issue.  Perhaps throw an error if both are present and conflict.  This may also mean the calling convention specifier at the call site needs to go away, but is this really needed?
> 
As Chris mentioned, this sounds like a good idea. We can explore that after the initial implementation. :)

-bw