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

Tue Nov 13 07:43:08 PST 2012

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?  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?

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?

On Tue, Nov 13, 2012 at 1:20 AM, Bill Wendling <wendling at apple.com> wrote:

> 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");
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121113/3268c3bb/attachment.html>