[LLVMdev] [RFC] Overhauling Attributes

[Reed Kotler]

Hi Bill,

This looks cool.

I'm definitely in need of this.

What is the recommendation for us to use for now until this is checked in.

I have attributes mips16 and nomips16 to add for Mips.

These would be function attributes.

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
>