[LLVMdev] [RFC] Overhauling Attributes

[Bill Wendling]

                         Overhauling Attributes

Problem
=======

LTO needs a way to pass options through to different parts of the compiler. In
particular, we need to pass code generation options to the back-end. The way we
want to do this is via the LLVM Attributes class. In order to do that, we need
to overhaul the Attributes class.

The Attributes class right now isn't very extensible. 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. It already
supports some of them (like SSP), but it isn't very extensible because it is a
fixed size bitfield. The size restriction also makes supporting options with
values very difficult. As the number of options grow, we will soon have run out
of space entirely.

Target-Specific Attributes in IR
================================

I propose that the target-specific attributes would be organized into groups.
Those groups would then be referenced by the functions directly. Here is an
example of what that could look like:

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

define void @func() noinline ssp attrgroup(#1) {
  ret void
}

Each target would know which options it can handle and how to parse them
correctly. Code generation would use the attribute group referenced by the
function to guide what code it emits.

First Step
==========

The first step of making a major change to attributes is to change the interface
for creating them into something that works with different designs. This will
allow the implementation to be swapped out independently of all the clients
changing. It would then expose a very simple predicate interface. Building
attributes for LLVM objects will be done with simple 'add*' methods:

An example syntax could be:

// Building an Attribute

Attributes A;
A.addAlignAttr(4)
 .addNoUnwindAttr()
 .addStackProtectorAttr()
 .addUnwindTableAttr()
 .addReadNoneAttr();

// Querying an Attribute

if (!A.hasStackProtector() || A.hasAlign(4))
   ...

The Attributes class will be expanded in the future to support code generation
and target-specific options. But it won't require a massive rewrite of the
compiler to do so.

The bit-wise operations on the Attributes class will need to be removed. This is
because the internals of the Attributes class may no longer be a bitfield.

Summary
=======

The Attributes class is going to change in some seriously fundamental ways, but
it will result in a much more extensible and flexible class. The changes to the
code base will be mostly mechanical in nature. The transition is easily
serialized, so any problems can be caught early on.