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