llvm dev - Oct 2010 - [LLVMdev] RFC: [Proposal] Module-Level Attributes

Module-Level Attributes


Overview
--------

LLVM currently lacks the ability to specify an attribute on a module as a
whole. This isn't typically a problem as most optimizations and code
transformations rely upon more finer-grained information, such as function
attributes. However, some transformations, in particular LTO, may need to know
information about the module. As a side-benefit, it could be used to reduce the
number of global variables which are currently used only to convey information
to the back-end, linker, et al.

Proposal
--------

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.

Example:

The Objective-C imageinfo section isn't merged correctly for the following.

t.mm:
#import <Foundation/Foundation.h>

NSAutoreleasePool *foo();

int main() {
  NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
  NSAutoreleasePool *pond = foo();
  return 0;
}

f.mm:
#import <Foundation/Foundation.h>

NSAutoreleasePool *foo() {
  return [[NSAutoreleasePool alloc] init];
}

$ llvm-g++ -fobjc-gc t.mm -c -flto
$ llvm-g++ -fno-objc-gc f.mm -c -flto
$ llvm-g++ t.o f.o -flto -framework Foundation
ld: warning: section __DATA/__objc_imageinfo__DATA has unexpectedly large size
16 in /tmp/lto.o
$

In this example, LTO is concatenating the imageinfo sections instead of
performing a proper merge.

Here are the LLVM global variables that contain the imageinfo information.

-fno-objc-gc:
@OBJC_IMAGE_INFO = private constant [2 x i32] [i32 0, i32 16], section
"__DATA, __objc_imageinfo, regular, no_dead_strip"

-fobjc-gc-only:
@OBJC_IMAGE_INFO = private constant [2 x i32] [i32 0, i32 22], section
"__DATA, __objc_imageinfo, regular, no_dead_strip"

With module-level attributes, these global variables wouldn't exist.
Instead,
they would be replaced by something like this:

-fno-objc-gc:
module attr ImageInfo [CorrectedSynthesize]

-fobjc-gc-only:
module attr ImageInfo [CorrectedSynthesize, GCOnly]

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

Comments?

-bw

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101028/7a8ff71e/attachment.html>

> 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

On 29 October 2010 01:46, Bill Wendling <wendling at apple.com>
wrote:
> 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.

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

On Oct 28, 2010, at 5:46 PM, Bill Wendling wrote:
> 
> Comments?
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101030/b8011806/attachment.html>

On Oct 29, 2010, at 5:52 PM, Rafael Espíndola wrote:
>> 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

On Oct 30, 2010, at 7:53 AM, Renato Golin wrote:
> On 29 October 2010 01:46, Bill Wendling <wendling at apple.com>
wrote:
>> 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 :-)

-bw

On Oct 30, 2010, at 9:28 AM, Dan Gohman wrote:
> 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