[LLVMdev] [RFC] Overhauling Attributes

[Bill Wendling]

On Sep 20, 2012, at 2:08 AM, Duncan Sands <baldrick at free.fr> wrote:

> 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?
> 
Not really. I want this to be separate from metadata. I don't expect that attribute groups will reference each other. And I want to keep the attributes that are stored as light weight as possible. However, I haven't come up with the complete proposal just yet.

> 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.
> 
Yeah, something like that. I'll look at Chris's note and see if I can incorporate it into the final design. :)

-bw