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

[Bill Wendling]

Hi!

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.

Thanks!
-bw

             Passing Options to Different Parts of the Compiler

Problem
=======

There is a growing need to pass information from the front-end to different parts
of the compiler, especially code generation. LTO, for instance, needs to encode
within the .o files the options it was compiled with. Otherwise, the code generator
could generate code that is unexpected -- e.g., generating SSE instructions when
the programmer used the `-mno-sse' flag to compile that module. After considering
several different options, we decided it was best to extend the Attributes class
to support *all* code generation options, even target-specific ones.


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 also allows for LTO
to merge files that were compiled with different options. It can determine if
it's possible to inline one function into another based upon the options with
which it was compiled. And finally, it's necessary for correctness. LTO
currently ignores the command line options with which a file was compiled.

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.

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.

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.:

 attrgroup #0 = { "long-calls", "cpu=cortex-a8", "thumb" }

 define void @func() attrgroup(#0) { ret void }

The ARM back-end is the only target that knows about these options and what to
do with them.

Some of the `cl::opt' options in the backend could move into attribute groups.
This will clean up the compiler.

Updating IR
-----------

The current attributes that are specified on functions will be moved into an
attribute group. The LLVM assembly reader will still honor those but when the
assembly file is emitted, those attributes will be output as an attribute group
by the assembly writer. As usual, LLVM 3.3 will be able to read and auto-upgrade
previous bitcode and `.ll' files.

Querying
--------

The attributes are attached to the function. It's therefore trivial to access
the attributes within the middle- and the back-ends. Here's an example of how
attributes are queried:

 Attributes &A = F.getAttributes();

 // Target-independent attribute query.
 A.hasAttribute(Attributes::NoInline);

 // Target-dependent attribute query.
 A.hasAttribute("no-sse");

 // Retrieving value of a target-independent attribute.
 int Alignment = A.getIntValue(Attributes::Alignment);

 // Retrieving value of a target-dependent attribute.
 StringRef CPU = A.getStringValue("cpu");