[llvm-commits] [Review] Attributes Documentation

[Bill Wendling]

On Dec 7, 2012, at 12:52 AM, James Molloy <james.molloy at arm.com> wrote:

> Hi Bill,
> 
> I'm not worried about the technical feasibility of any solution; rather
> that without careful thought this might prove a step *backwards* in
> terms of user-readability and debuggability.
> 
Uh...okay. Well, this isn't something that I just whipped up on a whim. It's been in the works for quite a while now. And the purpose of releasing the syntax to the community is to get as much feedback as possible.

Your comment of attribute groups changing during optimization passes isn't 100% correct. Once an attribute group is created, it's uniqued so it doesn't change. What happens when an attribute is "added," a new (uniqued) attribute group is returned. This shouldn't impact debugging. The syntax is such that it should have better user readability, especially once we start adding many more attributes (consider how a slew of attributes would look on a CallInst).

-bw

> On Thu, 2012-12-06 at 20:39 +0000, Bill Wendling wrote:
>> On Dec 6, 2012, at 12:55 AM, James Molloy <James.Molloy at arm.com> wrote:
>> 
>>> Hi Bill,
>>> 
>>> On Thu, 2012-12-06 at 02:01 +0000, Bill Wendling wrote:
>>>> In practice, there won't be a large number of differences between
>>>> functions. The attributes come about in only a few ways:
>>>> 
>>>>       - through command line options
>>>>       - via '__attribute__' declarations
>>> 
>>> You forget compiler-added annotations such as
>>> readonly/readnone/noreturn, which can serve as analysis markers. These
>>> can get added during optimization passes, so your IR attribute groups
>>> are going to change during optimization passes (eww).
>>> 
>> I forgot about those. But yes, they're changeable. And that's fine. They'll just be given a new attributes object or added onto a list (or set) of attribute objects. The internal representation is still in flux right now. :)
>> 
>> -bw