[LLVMdev] RFC: [Proposal] Module-Level Attributes

Bill Wendling wendling at apple.com
Sat Oct 30 19:00:42 PDT 2010


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





More information about the llvm-dev mailing list