[LLVMdev] [RFC] Overhauling Attributes

Reed Kotler rkotler at mips.com
Fri Jan 11 15:09:44 PST 2013

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?


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

More information about the llvm-dev mailing list