[RFC] Attributes Rewrite (Final)

Hi!

The rewrite of the attributes class is well underway. The next step is to add support for the expanded rôle of attributes in the language and IR. This is the final proposal for the language changes. There isn't a lot of new information except for the syntax changes for the new feature.

Executive Summary:

The new syntax is:

  #0 = attributes { noinline align=4 "cpu"="cortex-a8" }
  #1 = attributes { attr = (val1 val2 val3) }
  #bork = attributes { sspreq noredzone }

  define void @foo() #0 #bork { ret void }

The 'align' and "cpu" attributes both have a value associated with them. The 'attr' attribute in '#1' has multiple values associated with it. (The BNF is below in the 'IR Changes' section.) Attribute groups with the same attributes in them, but in a different order, are identical. So '@bar' and '@qux' have the same attributes in this example:

  #0 = attributes { align=4 }
  #1 = attributes { sspreq noredzone }
  #2 = attributes { noredzone sspreq align=4 noinline }

  define void @bar() noinline #0 #1 { ret void }
  define void @qux() #2 { ret void }

When run through 'llvm-as', the disassembly will look similar to this:

  #0 = attributes { noredzone sspreq align=4 noinline }

  define void @bar() #0 { ret void }
  define void @qux() #0 { ret void }

Thanks!
-bw

            Passing Options to Different Parts of the Compiler

Problem

Executive Summary:

The new syntax is:

  #0 = attributes { noinline align=4 "cpu"="cortex-a8" }
  #1 = attributes { attr = (val1 val2 val3) }
  #bork = attributes { sspreq noredzone }

  define void @foo() #0 #bork { ret void }

The general syntax LGTM. It seems clean and fits well with what we have.

The 'align' and "cpu" attributes both have a value associated with them. The 'attr' attribute in '#1' has multiple values associated with it. (The BNF is below in the 'IR Changes' section.) Attribute groups with the same attributes in them, but in a different order, are identical. So '@bar' and '@qux' have the same attributes in this example:

What is the use case for the multi-value attribute? Perhaps obvious, but it makes sense to stage this out to add one thing at a time. Also, your BNF doesn't make it clear what is allowed for <value>: I would assume it is a set of hardcoded keywords (like align, sspreq, etc) plus the string form. If so, how does "val1" fit into that?

Proposal

We will expand the Attriutes class to support all of the attributes that the
compiler may care about. Anything that affects code transformations and code
generation will be specified inside of the Attributes class. This allows for a
cleaner interface for the front-ends, since they won't have to fill in a
target-specific structure to pass along this information.

It will also hopefully allow us to eliminate most or all of the "global" variables crammed into the TargetOptions class.

There are two classes of attributes: those that are target-independent (e.g.,
'noinline'), and those that are target-dependent (e.g., 'thumb' and
'cpu=cortex-a8'). The target-dependent options are stored as strings inside of
the Attributes class. The target's back-end is responsible for interpreting
target-dependent attributes.

Attributes should be documented in the language reference document.

Target specific attributes should probably be listed in the target-specific section of docs/CodeGenerator.rst.

The core of this proposal is the idea of an "attribute group". As the name
implies, it's a group of attributes that are then referenced by objects within
the IR. An attribute group is a module-level object. The BNF of the syntax is:

attribute_group := <attrgroup_id> '=' attributes '{' <attribute_list> '}'
attrgroup_id := #<id>
attribute_list := <attribute> <attribute>*
attribute := <name> ('=' <list_of_values>)?
list_of_values := <value> | '(' <value> <value>* ')'
id := <number> | <name>

As mentioned above, it is unclear what "value" is. It makes sense to me to make it one of a hard-coded list of well-known stuff we know about (like align) plus double-quoted strings, used for target-specific stuff.

Attribute groups are important for keeping `.ll' files readable, because a lot
of functions will use the same attributes. In the degenerative case of a `.ll'
file that corresponds to a single `.c' file, the single `attrgroup' will capture
the command line flags used to build that file.

It's worth noting that the structure of attribute groups is an .ll file syntax thing, they aren't reflected in the IR once parsed.

Target-Dependent Attributes in IR
---------------------------------

The front-end is responsible for knowing which target-dependent options are
interesting to the target. Target-dependent attributes are specified as strings,
which are understood by the target's back-end. E.g.:

  #0 = attributes { "long-calls", "cpu=cortex-a8", "thumb" }

"cpu=cortex-a8" or "cpu"="cortex-a8"?

-Chris

Executive Summary:

The new syntax is:

   #0 = attributes { noinline align=4 "cpu"="cortex-a8" }
   #1 = attributes { attr = (val1 val2 val3) }
   #bork = attributes { sspreq noredzone }

   define void @foo() #0 #bork { ret void }

The general syntax LGTM. It seems clean and fits well with what we have.

Thanks! :slight_smile:

The 'align' and "cpu" attributes both have a value associated with them. The 'attr' attribute in '#1' has multiple values associated with it. (The BNF is below in the 'IR Changes' section.) Attribute groups with the same attributes in them, but in a different order, are identical. So '@bar' and '@qux' have the same attributes in this example:

What is the use case for the multi-value attribute? Perhaps obvious, but it makes sense to stage this out to add one thing at a time. Also, your BNF doesn't make it clear what is allowed for <value>: I would assume it is a set of hardcoded keywords (like align, sspreq, etc) plus the string form. If so, how does "val1" fit into that?

I added it because I wanted to limit possible future changes to the IR. But that may be premature. It would essentially act like the '-mattr' command line option works today. Of course the -mattr functionality is covered by this proposal. I will omit that part and leave it for a future expansions if necessary. It won't be a major change to the IR at that point.

My first thoughts about what <value> can be is something that can be represented by a Constant object. So a keyword, string, or numerical value. I expect string values to be used mainly for target-dependent attributes. The other two forms would be used for target-independent attributes defined in the LangRef.

Proposal

We will expand the Attriutes class to support all of the attributes that the
compiler may care about. Anything that affects code transformations and code
generation will be specified inside of the Attributes class. This allows for a
cleaner interface for the front-ends, since they won't have to fill in a
target-specific structure to pass along this information.

It will also hopefully allow us to eliminate most or all of the "global" variables crammed into the TargetOptions class.

God-willing, yes! :slight_smile:

There are two classes of attributes: those that are target-independent (e.g.,
'noinline'), and those that are target-dependent (e.g., 'thumb' and
'cpu=cortex-a8'). The target-dependent options are stored as strings inside of
the Attributes class. The target's back-end is responsible for interpreting
target-dependent attributes.

Attributes should be documented in the language reference document.

Target specific attributes should probably be listed in the target-specific section of docs/CodeGenerator.rst.

Okay, that makes sense.

The core of this proposal is the idea of an "attribute group". As the name
implies, it's a group of attributes that are then referenced by objects within
the IR. An attribute group is a module-level object. The BNF of the syntax is:

attribute_group := <attrgroup_id> '=' attributes '{' <attribute_list> '}'
attrgroup_id := #<id>
attribute_list := <attribute> <attribute>*
attribute := <name> ('=' <list_of_values>)?
list_of_values := <value> | '(' <value> <value>* ')'
id := <number> | <name>

As mentioned above, it is unclear what "value" is. It makes sense to me to make it one of a hard-coded list of well-known stuff we know about (like align) plus double-quoted strings, used for target-specific stuff.

That sounds reasonable.

Attribute groups are important for keeping `.ll' files readable, because a lot
of functions will use the same attributes. In the degenerative case of a `.ll'
file that corresponds to a single `.c' file, the single `attrgroup' will capture
the command line flags used to build that file.

It's worth noting that the structure of attribute groups is an .ll file syntax thing, they aren't reflected in the IR once parsed.

Yes. In particular, we won't be trying to preserve the .ll syntax when it's run through llvm-as and llvm-dis.

Target-Dependent Attributes in IR
---------------------------------

The front-end is responsible for knowing which target-dependent options are
interesting to the target. Target-dependent attributes are specified as strings,
which are understood by the target's back-end. E.g.:

   #0 = attributes { "long-calls", "cpu=cortex-a8", "thumb" }

"cpu=cortex-a8" or "cpu"="cortex-a8"?

The latter.

-bw

To use an attribute group, an object references the attribute group's ID:

attribute_group_ref := attrgroup(<attrgroup_id>)

Is this unused now? I don't see it anywhere else in the proposal.

-- Sean Silva

The 'align' and "cpu" attributes both have a value associated with them. The 'attr' attribute in '#1' has multiple values associated with it. (The BNF is below in the 'IR Changes' section.) Attribute groups with the same attributes in them, but in a different order, are identical. So '@bar' and '@qux' have the same attributes in this example:

What is the use case for the multi-value attribute? Perhaps obvious, but it makes sense to stage this out to add one thing at a time. Also, your BNF doesn't make it clear what is allowed for <value>: I would assume it is a set of hardcoded keywords (like align, sspreq, etc) plus the string form. If so, how does "val1" fit into that?

I added it because I wanted to limit possible future changes to the IR. But that may be premature. It would essentially act like the '-mattr' command line option works today. Of course the -mattr functionality is covered by this proposal. I will omit that part and leave it for a future expansions if necessary. It won't be a major change to the IR at that point.

Ok, I'd prefer that you not implement this yet. When/if a need comes up, we can consider it then, and taking into consideration the specific use case.

My first thoughts about what <value> can be is something that can be represented by a Constant object. So a keyword, string, or numerical value. I expect string values to be used mainly for target-dependent attributes. The other two forms would be used for target-independent attributes defined in the LangRef.

Ok, seems reasonable. I assume you don't mean ConstantData, ConstantFP, ... though, right?

-Chris

This was replaced by having a #<num> referenced by the object. Kind of like how metadata is referenced.

-bw

Yeah. :slight_smile:

Great! I'll start moving forward on this.

-bw

Hi,

I would like to link my code with a Makefile like

target : $(OBJECTS)
               $(LLVM_LINK) `llvm-config --ldflags` $(OBJECTS) `llvm-config --libs`

But this does not work because
`llvm-config --ldflags` output is

-L/usr/local/llvm/3.2/lib -lpthread -ldl -lm

and `llvm-config --libs` output is a long list of libraries
-lLLVMAsmParser -lLLVMInstrumentation -lLLVMLinker -lLLVMArchive -lLLVMBitReader -lLLVMDebugInfo -lLLVMJIT etc.

But the problem is that "-lpthread -ldl -lm" should be placed after OBJECTS
although -L/usr/local/llvm/3.2/lib should indeed be placed before.

Any advice ?

Vania