[cfe-dev] [PATCH] Wrap clang modules inside Mach-O/ELF/COFF containers

Jordan Rose jordan_rose at apple.com
Thu Dec 11 16:39:09 PST 2014


> On Dec 11, 2014, at 16:30 , Adrian Prantl <aprantl at apple.com> wrote:
> 
>> 
>> On Dec 11, 2014, at 3:37 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com> wrote:
>> 
>> 
>>> On Dec 11, 2014, at 3:08 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>>> 
>>> On Thu, Dec 11, 2014 at 3:00 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com> wrote:
>>> 
>>>> On Dec 11, 2014, at 2:59 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>>>> 
>>>> On Thu, Dec 11, 2014 at 2:40 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com> wrote:
>>>> The .pcm file is currently independent of debug info, meaning the compiler invocation will be able to use the same .pcm file regardless of whether the invocation had enabled debug info or not;
>>>> 
>>>> We can't use the same .pcm file for -DNDEBUG vs -UNDEBUG builds. Do we ever get to reuse a .pcm file like this in practice?
>>> 
>>> You can choose to add, or not to add, debug info to a release build.
>>> 
>>> Sure, I don't dispute that this .pcm reuse can happen in theory. But what I'm wondering is: Does this actually happen in practice? How often? Is this case worth optimizing for?
>>> 
>>> There are other things I'd like to bundle with a .pcm file (.o and .ir code for inline functions, for instance) that would also benefit from using an ELF wrapper format, and would also vary based on clang's CodeGen options. One possible approach would be to have (at least) two files -- one CodeGen-independent AST file, and one CodeGen-dependent file containing all the other bits -- but that seems to introduce complexity that is unnecessary in almost all cases. (Also note that even flags like -O or -fsanitize=address cause us to build different .pcm files today, because they affect preprocessor macros.)
>> 
>> I don’t see the reason to make the module file itself the container, particularly when whatever the container may contain doesn’t affect in any way the semantic info that the module file is supposed to provide, we just proliferate module files and/or rebuild module files unnecessarily.
>> It’s true that the situation is not ideal currently and we have -O[1 ~ 3] reusing the .pcm but -Os does not, but in the future we could try to address this, not make the situation fundamentally worse and inescapable. I’d like that modules not turn into a “glorified PCH system" where there is practically zero re-use for them.
>> 
>> Back to the debug info, why not have the container like this
>> 
>> Foundation.pcm.o
>>   \
>>  Foundation.pcm
>> 
>> where the container references the .pcm file, and you can put the debug info in it (or ir later on).
>> 
>> Debug info can reference Foundation.pcm.o and get extended to handle the serialized AST from .pcm.
> 
> At least for the debug info I was hoping that it would be cheap enough to always emit it together with the pcm, especially given that modules are being rebuilt comparatively infrequently. The module debug info is essentially just an alternative encoding of the types provided by the module, and exactly same conditions that trigger a re-generation of the .pcm today would also necessitate re-generating the debug info.
> 
> If we do want to hold on to the ability of having modules without debug info this approach does appears a little less practical.
> 
> Having two separate files complicates the module rebuild stage a bit and we will need to also store a hash of the module to make sure the two files are in sync, but it would certainly be doable. It would probably be easier to provide non-debuggable modules this way.
> 
> Are modules without debug info desirable? Translating types to DWARF is relatively cheap and it is my understanding that modules are not rebuilt very often and since the module cache is shared across all projects.

The module cache is essentially never shared across projects because it depends on include paths and macros. I think there are sound ways to improve this, but no one's looking into it right now.

Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141211/1008cee6/attachment.html>


More information about the cfe-dev mailing list