RFC: [Proposal] Module-Level Attributes

Module-Level Attributes

Overview

LTO would see that the module attributes are incompatible and will reject
trying
to link the two modules.
Comments?

Just questions since I am not familiar with objc:

*) Is the native linker able to handle this if you don't use LTO?
*) -fobjc-gc/-fno-objc-gc have any other impact on functions or data
structures? Could you use these to detect the problem?

I am just a bit concerned that llvm-extract (and therefore bugpoint)
will not work correctly for functions that have a dependency on file
attributes. If it is not easy to detect the above issues by looking at
function signatures or something similar, the above proposal looks
like a reasonable way to do it.

Can you constrain that, in the LTO level, the module attributes are
used only to check for compatibility? Once the modules are found to me
compatible and merged the attributes can still impact codegen.

-bw

Cheers,
Rafael

Hi Bill,

This sounds very similar with my proposal to introduce ARM build
attributes as a module level property (pretty much like data layout
and target triple). You can specify restrictions that you passed via
the front-end and get them propagated all the way to the back end,
even if you're compiling in separate steps, linking objects from
different processes.

Allowing target-dependent attributes to be set (ie. not verified by
the front-end), you wouldn't pollute x86 modules with ARM build
attributes or C++ modules with Objective-C attributes.

An alternative would be to use metadata for that, as was proposed
already due to it's non-checked nature, but metadata needs a real
Value to remain in the module, and that's precisely what you're trying
to avoid.

I, for one, vote in favour of having module attributes.

cheers,
--renato

Hi Bill,

This is a broad solution to what sounds like a specific problem. Are there any
other uses for module-level attributes anticipated?

Do you anticipate defining what ImageInfo, CorrectedSynthesize, GCOnly, etc.
mean in LangRef.html, or are they just going to be left as “The is for ObjC.” ?

Thanks,

Dan

LTO would see that the module attributes are incompatible and will reject
trying
to link the two modules.
Comments?

Just questions since I am not familiar with objc:

*) Is the native linker able to handle this if you don't use LTO?

The back-end will be responsible for generating the correct imageinfo section based on the attributes. So there will be no functionality change for non-LTO linkage.

*) -fobjc-gc/-fno-objc-gc have any other impact on functions or data
structures? Could you use these to detect the problem?

Do be honest, I don't know enough about these flag to say. However, it does appear that in this case the only effect of these flags is in the imageinfo section. Any other changes would be done by the front-end.

I am just a bit concerned that llvm-extract (and therefore bugpoint)
will not work correctly for functions that have a dependency on file
attributes. If it is not easy to detect the above issues by looking at
function signatures or something similar, the above proposal looks
like a reasonable way to do it.

Can you constrain that, in the LTO level, the module attributes are
used only to check for compatibility? Once the modules are found to me
compatible and merged the attributes can still impact codegen.

I agree that these attributes should be restricted to module-level information, and not impact functions the way function attributes do. That said, I think that llvm-extract would need to copy the module attributes over into the new .bc file.

However, this does go beyond just supporting LTO (though that is the impetus for this feature proposal). So I still want them to impact codegen regardless. It's just a question of what will be impacted. In this case (and I suspect most cases), it's information about what to put in different DATA sections (and in some cases what to name those sections) and not how to transform executable code.

-bw

Syntax:
   ml-attr ::= 'module' 'attr' NAME ('[' NAME (',' NAME)* ']')?
where the optional list of NAMEs in the square brackets represents sub-attributes
of the main attribute.
Semantics:
Module-level attributes are looked at only by those parts of the compiler which
care about them. Deleting a module attribute may effect code generation.
Each module-level attribute will have its own documented semantics for
how it may be used.

Hi Bill,

This sounds very similar with my proposal to introduce ARM build
attributes as a module level property (pretty much like data layout
and target triple). You can specify restrictions that you passed via
the front-end and get them propagated all the way to the back end,
even if you're compiling in separate steps, linking objects from
different processes.

Cool! I missed your proposal. Do you have a link to it?

Allowing target-dependent attributes to be set (ie. not verified by
the front-end), you wouldn't pollute x86 modules with ARM build
attributes or C++ modules with Objective-C attributes.

An alternative would be to use metadata for that, as was proposed
already due to it's non-checked nature, but metadata needs a real
Value to remain in the module, and that's precisely what you're trying
to avoid.

The other problem with metadata is that it's not may be removed at any point in the compilation process. So you cannot depend upon it being there.

I, for one, vote in favour of having module attributes.

Thanks :slight_smile:

-bw

Hi Bill,

This is a broad solution to what sounds like a specific problem. Are there any
other uses for module-level attributes anticipated?

I asked this same question to Chris and the answer is "yes." Objective-C is the obvious benefactor of this proposal, because it relies so heavily on metadata. But there's no reason that it should be restricted to just ObjC.

Do you anticipate defining what ImageInfo, CorrectedSynthesize, GCOnly, etc.
mean in LangRef.html, or are they just going to be left as "The is for ObjC." ?

They and all other attributes will be explicitly defined in LangRef.html.

-bw

Cool! I missed your proposal. Do you have a link to it?

It was in the list, a few weeks ago. Can't seem to find it, though.
I'll talk about this in the dev meeting next week.

The other problem with metadata is that it's not may be removed at any point in the compilation process. So you cannot depend upon it being there.

Agreed. Metadata is for hints, not dependencies.

cheers,
--renato