[LLVMdev] [RFC] Overhauling Attributes

[Reed Kotler]

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