<div>Couple of quick questions:</div><div><br></div><div>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?  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?</div>
<div><br></div><div>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?</div>
<div><br></div>On Tue, Nov 13, 2012 at 1:20 AM, Bill Wendling <span dir="ltr"><<a href="mailto:wendling@apple.com" target="_blank">wendling@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<br>
This is a proposal to expand the Attributes class to support many different options that will be accessible by all parts of the compiler. Please read and give any feedback you may have.<br>
<br>
Thanks!<br>
-bw<br>
<br>
             Passing Options to Different Parts of the Compiler<br>
<br>
Problem<br>
=======<br>
<br>
There is a growing need to pass information from the front-end to different parts<br>
of the compiler, especially code generation. LTO, for instance, needs to encode<br>
within the .o files the options it was compiled with. Otherwise, the code generator<br>
could generate code that is unexpected -- e.g., generating SSE instructions when<br>
the programmer used the `-mno-sse' flag to compile that module. After considering<br>
several different options, we decided it was best to extend the Attributes class<br>
to support *all* code generation options, even target-specific ones.<br>
<br>
<br>
Proposal<br>
========<br>
<br>
We will expand the Attriutes class to support all of the attributes that the<br>
compiler may care about. Anything that affects code transformations and code<br>
generation will be specified inside of the Attributes class. This allows for a<br>
cleaner interface for the front-ends, since they won't have to fill in a<br>
target-specific structure to pass along this information. It also allows for LTO<br>
to merge files that were compiled with different options. It can determine if<br>
it's possible to inline one function into another based upon the options with<br>
which it was compiled. And finally, it's necessary for correctness. LTO<br>
currently ignores the command line options with which a file was compiled.<br>
<br>
There are two classes of attributes: those that are target-independent (e.g.,<br>
'noinline'), and those that are target-dependent (e.g., 'thumb' and<br>
'cpu=cortex-a8'). The target-dependent options are stored as strings inside of<br>
the Attributes class. The target's back-end is responsible for interpreting<br>
target-dependent attributes.<br>
<br>
Attributes should be documented in the language reference document.<br>
<br>
IR Changes<br>
----------<br>
<br>
The attributes will be specified within the IR. This allows us to generate code<br>
that the user wants. This also has the advantage that it will no longer be<br>
necessary to specify all of the command line options when compiling the bit code<br>
(via 'llc' or 'clang'). E.g., '-mcpu=cortex-a8' will be an attribute and won't<br>
be required on llc's command line. However, explicit flags (like `-mcpu') on the<br>
llc command line will override flags specified in the module.<br>
<br>
The core of this proposal is the idea of an "attribute group". As the name<br>
implies, it's a group of attributes that are then referenced by objects within<br>
the IR. An attribute group is a module-level object. The BNF of the syntax is:<br>
<br>
 attribute_group := attrgroup <attrgroup_id> = { <attribute_list> }<br>
 attrgroup_id    := #<number><br>
 attribute_list  := <attribute> (, <attribute>)*<br>
 attribute       := <name> (= <value>)?<br>
<br>
To use an attribute group, an object references the attribute group's ID:<br>
<br>
 attribute_group_ref := attrgroup(<attrgroup_id>)<br>
<br>
This is an example of an attribute group for a function that should always be<br>
inlined, has stack alignment of 4, and doesn't unwind:<br>
<br>
 attrgroup #1 = { alwaysinline, nounwind, alignstack=4 }<br>
<br>
 void @foo() attrgroup(#1) { ret void }<br>
<br>
An object may refer to more than one attribute group. In that situation, the<br>
attributes are merged.<br>
<br>
Attribute groups are important for keeping `.ll' files readable, because a lot<br>
of functions will use the same attributes. In the degenerative case of a `.ll'<br>
file that corresponds to a single `.c' file, the single `attrgroup' will capture<br>
the command line flags used to build that file.<br>
<br>
Target-Dependent Attributes in IR<br>
---------------------------------<br>
<br>
The front-end is responsible for knowing which target-dependent options are<br>
interesting to the target. Target-dependent attributes are specified as strings,<br>
which are understood by the target's back-end. E.g.:<br>
<br>
 attrgroup #0 = { "long-calls", "cpu=cortex-a8", "thumb" }<br>
<br>
 define void @func() attrgroup(#0) { ret void }<br>
<br>
The ARM back-end is the only target that knows about these options and what to<br>
do with them.<br>
<br>
Some of the `cl::opt' options in the backend could move into attribute groups.<br>
This will clean up the compiler.<br>
<br>
Updating IR<br>
-----------<br>
<br>
The current attributes that are specified on functions will be moved into an<br>
attribute group. The LLVM assembly reader will still honor those but when the<br>
assembly file is emitted, those attributes will be output as an attribute group<br>
by the assembly writer. As usual, LLVM 3.3 will be able to read and auto-upgrade<br>
previous bitcode and `.ll' files.<br>
<br>
Querying<br>
--------<br>
<br>
The attributes are attached to the function. It's therefore trivial to access<br>
the attributes within the middle- and the back-ends. Here's an example of how<br>
attributes are queried:<br>
<br>
 Attributes &A = F.getAttributes();<br>
<br>
 // Target-independent attribute query.<br>
 A.hasAttribute(Attributes::NoInline);<br>
<br>
 // Target-dependent attribute query.<br>
 A.hasAttribute("no-sse");<br>
<br>
 // Retrieving value of a target-independent attribute.<br>
 int Alignment = A.getIntValue(Attributes::Alignment);<br>
<br>
 // Retrieving value of a target-dependent attribute.<br>
 StringRef CPU = A.getStringValue("cpu");<br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div><br>
</div>