[llvm-commits] [Review] Attributes Documentation

[Bill Wendling]

On Dec 6, 2012, at 2:50 AM, Renato Golin <rengolin at systemcall.org> wrote:

> On 6 December 2012 02:01, Bill Wendling <wendling at apple.com> wrote:
>>> I personally think that having the attributes on the functions is
>>> *much* better, on the textual form, than having to check them
>>> somewhere else in the IR.
>>> 
>> This becomes very unwieldy once you start expanding the number of attributes you have. It leads to a very hard to read function signature.
> 
> Maybe the textual representation is not good. Maybe if you dump the
> attributes on a second line, before/after the function declaration,
> it'd make it clearer without changing the logic behind them.
> 
But this doesn't address the use of attributes on function calls.

>> 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
>> 
>> So most functions within a TU will have the same set of attributes. A handful will be different, but it shouldn't result in a combinatorial explosion of attribute groups. In fact, the uniquing and allowing a function to reference multiple attribute groups is meant to alleviate the number of attribute groups that are generated.
> 
> Yes, possibly I was being a bit over dramatic, but there is a point to
> it. As James pointed out, IR passes do add / change attributes, and
> others rely on them to optimize or not.
> 
> What I fear is that, for huge modules (for instance, when linking
> several bc files together), things can get out of proportion really
> quickly. I believe PNaCl does that when distributing programs, and JIT
> environments (correct me if I'm wrong), I believe, end up working with
> big blobs or IR in memory.
> 
> Linkers already have to deal with the painful problem of merging
> symbols, it looks to me that we're adding another painful problem for
> the sake of textual readability (is this the only reason?), that can
> be solved solely within the boundaries of textual representation.
> 
The problem isn't just textual readability. I'm trying to solve how best to represent attributes on IR objects (functions in this case). Having attribute groups allows us to collate attributes into one place. It's the cleanest interface for this type of problem. As I mentioned above, it's not only function declarations and definitions which have the function attributes on them. It really does become unwieldy when you start considering that there may be a *lot* of attributes that we want to add.

-bw