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