[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?
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
>
More information about the llvm-dev
mailing list