[LLVMdev] [RFC] Overhauling Attributes

[Duncan Sands]

Hi Bill,

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

does this mean you would like attributes to form a tree structure?  This sounds
a lot like metadata, only metadata that can't be thrown away - do you think it
feasible to have this and metadata share code, eg each be derived from some
common parent class?

Allowing values for attributes would also be great for implementing something
Chris suggested in one of his notes: getting rid of the "zext" attribute, which
means that some (eg) i16 parameter is magically zext'd to an unspecified larger
type like i32, and instead having the larger type i32 be the parameter type
with a "zexted from i16" attribute on it.  This could be done as "zexted=i16"
with your system I guess.

Ciao, Duncan.

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