[LLVMdev] [RFC] Overhauling Attributes

[Bill Wendling]

Oops! Sorry...This got skipped by me.

I'm not sure what the recommended approach should be here. I don't like you modifying the IR to add the 'target' keyword. Would this be an acceptable hack? Create a global variable "@llvm.mips16" or whatever. That global would list the functions which have that attribute. Those which aren't in the list would have the attribute "nomips16".

Alternatively, you could create a module flag which takes a list of functions that have that attribute:

!0 = metadata !{ i32 1, metadata !"mips16", !{ i32 ()* @foo, i32 ()* @bar } }

!llvm.module.flags = !{ !0 }

-bw

On Jan 11, 2013, at 3:41 PM, Reed Kotler <rkotler at mips.com> wrote:

> Looks like new attribute work is moving along quickly
> 
> Maybe I should just wait.
> 
> ???
> On 01/11/2013 03:09 PM, Reed Kotler wrote:
>> I would like to add something to atttributes.h, attributes.cpp in the
>> interim until your full scheme is available.
>> 
>> A new attribute called "target" would be added to AttrKind.
>> 
>> And target can take a list of strings.
>> 
>> target("foo", "goo")
>> 
>> For example.
>> 
>> I would add a component targetAttrs to AttrBuilder
>> 
>> Will this meet with resistance if I try and put this back?
>> 
>> Reed
>> 
>> On 01/01/2013 04:07 AM, Bill Wendling wrote:
>>> On Dec 31, 2012, at 4:37 AM, Duncan Sands <baldrick at free.fr> wrote:
>>> 
>>>> Hi Bill,
>>>> 
>>>> On 30/12/12 03:21, Bill Wendling wrote:
>>>>> Hi Rafael,
>>>>> 
>>>>> Sorry, I forgot to respond to this. They can be arbitrary strings
>>>>> that are known only to the specific back-end. It may be beneficial
>>>>> to define them inside of the LangRef document though.
>>>> 
>>>> this sounds so much like metadata...  What was the reason for not
>>>> enhancing
>>>> metadata to cover this use case?  I'm sure you explained but I've
>>>> completely
>>>> forgotten...
>>>> 
>>> Hi Duncan,
>>> 
>>> There are a couple of reasons why I don't think it's a good idea to
>>> use metadata (or more specifically, the module-level flags). Firstly,
>>> everything would have to be specified as a strings: "noinline", "ssp",
>>> etc., because a metadata object can hold only a Value type. Secondly,
>>> I don't want to have a "loop" in the attributes:
>>> 
>>>   !1 = metadata !{ !"noinline", !2 }
>>>   !2 = metadata !{ !1, !"ssp" }
>>> 
>>> This makes uniquifying the attributes that much harder.
>>> 
>>> We also want to be able to intelligently merge the attribute groups.
>>> These two groups are identical:
>>> 
>>>   #1 = attributes { noredzone noinline sspreq "mcpu"="cortex-a8" }
>>>   #2 = attributes { "mcpu"="cortex-a8" sspreq noinline noredzone }
>>> 
>>> Which brings up the '<kind>=<value>' syntax. The ability to have
>>> (possibly multiple) values assigned to an attribute kind isn't
>>> something easily modeled in metadata, as far as I can tell.
>>> 
>>> These (and maybe a few more, it's late) are some of the reasons why I
>>> feel a new first-class IR construct is needed. It's possible to modify
>>> metadata to handle these. But I feel that it's much more cumbersome to
>>> do that.
>>> 
>>> -bw
>>> 
>