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. -bw On Oct 4, 2012, at 7:47 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:>> attrgroup #1 = { "long-calls", "cpu=cortex-a8", "thumb" } >> >> define void @func() noinline ssp attrgroup(#1) { >> ret void >> } >> > > I like the general idea. Just one clarification: In the above example, > are the attributes taken from a list specified in the language ref > (like current attributes) or can they be arbitrary "strings" (like > metadata)? > > Cheers, > Rafael
On 29 December 2012 21:21, Bill Wendling <wendling at apple.com> 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.But then, what are the semantics that the middle end should use? Can a non thumb function be inlined in a thumb one for example? If we merge two functions, how should we combine the attributes? Or should this not be a valid optimization at all?> -bw >Cheers, Rafael
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... Ciao, Duncan.> > -bw > > On Oct 4, 2012, at 7:47 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >>> attrgroup #1 = { "long-calls", "cpu=cortex-a8", "thumb" } >>> >>> define void @func() noinline ssp attrgroup(#1) { >>> ret void >>> } >>> >> >> I like the general idea. Just one clarification: In the above example, >> are the attributes taken from a list specified in the language ref >> (like current attributes) or can they be arbitrary "strings" (like >> metadata)? >> >> Cheers, >> Rafael > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
> 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...I was assuming the difference was that attributes cannot be removed in general. But then the only options I can see are * Document the semantics of all of them. * Find some other generic way by which the middle end can handle an unknown attribute.> Ciao, Duncan. >Cheers, Rafael
On Dec 30, 2012, at 11:35 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:> On 29 December 2012 21:21, Bill Wendling <wendling at apple.com> 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. > > But then, what are the semantics that the middle end should use? Can a > non thumb function be inlined in a thumb one for example? If we merge > two functions, how should we combine the attributes? Or should this > not be a valid optimization at all? >All good questions. The initial implementation will be a very conservative "if the attributes don't match, then we won't inline them." Yes, that's horribly bad in general, but shouldn't be too much of a problem in non-LTO cases. This can be relaxed later on. For target-specific attributes, we will have to rely upon the back-end to tell us if it's okay to inline them. -bw
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