[llvm-commits] [Review] Attributes Documentation

[Renato Golin]

On 6 December 2012 02:01, Bill Wendling <wendling at apple.com> wrote:
> Attributes are already uniqued today. It's done with enums and such. :)

Yes, I read your reply to the other thread. It only makes sense. ;)


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


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


--
cheers,
--renato

http://systemcall.org/