[llvm-commits] [Review] Attributes Documentation

[Bill Wendling]

On Dec 5, 2012, at 12:56 AM, James Molloy <James.Molloy at arm.com> wrote:

> Hi Bill,
> 
> A couple of comments:
> 
> ====
> 
> It seems strange to me that attribute groups cannot be named, and *must*
> be referred to by number. It is at odds with how registers, globals and
> named metadata work. Is there any reason why they can't be named
> entities?
> 
After thinking about this, I've decided to take Meador's suggestion and allow non-numeric names for the attribute groups. I couldn't think of a valid reason why they couldn't be named. :)

> ====
> 
> How does uniquing work?
> 
The internal data structure is uniqued for each group of attributes.

> attributes #0 = { noinline, optsize }
> attributes #1 = { noinline, optsize }
> 
These would be the same attribute object internally.

> declare void @f() #0
> define void @g() {
>  call void @f() #1
>  ret void
> }
> 
> That you can define @f with one attribute group but call it with another
> is confusing. I can see it becoming *very* confusing when using multiple
> attribute groups - do I know that "#0 #1" and "#2 #3" are equivalent? Is
> this a valid call? I can see it adding headaches to read the IR,
> especially if they are numeric-only and not nameable (see above).
> 
Um...don't do that. :) Seriously, that's the suggestion. It's one of the problems with uniquing things. For instance, if MDNodes were properly uniqued, then !0 would have two operands, which pointed to the same MDNode internally:

	!0 = metadata !{ metadata !1, metadata !2 }
	!1 = metadata !{ i64 42 }
	!2 = metadata !{ i64 42 }

The above is saved in bitcode as 2 metadata objects: !0 and !1.

> Could we make attribute groups unique? so in the example above, this
> would be illegal as #0 and #1 are equivalent?
> 
It shouldn't work like that. Currently, function attributes are not part of the function type. So it would be legal to have a call that lists different function attributes than the declaration/definition. That won't change under this new scheme.

> In fact, the LangRef doesn't mention if the above is correct. Even if
> attribute groups #0 and #1 are the same, is it legal to call with #1 a
> function defined with #0?
> 
Yes.

> ====
> 
> Why is the syntax backwards? Metadata are defined like this:
> 
> !x = metadata { ... }
> 
> whereas attributes are defined like this:
> 
> attributes #0 = { ... }
> 
> This seems weird. Can we not standardise it?
> 
I actually based this off of the module-level asm syntax. (In an earlier version, there was a 'module' keyword before the 'attributes' keyword.)

I'm not a big fan of the metadata syntax. One reason I can think of for why metadata is written that way is because metadata lets one metadata object reference another. So there's a 'metadata' keyword placed in front of it. I'm not going to allow attribute groups to reference each other.

-bw