[cfe-dev] modules: cyclic dependency, performance questions

[Thompson, John]

Hi,

I'm trying to set up modules for some platform headers that are found in 3 separate subdirectories:

(platform)/target/include
(platform)/target/include_common
(platform)/host_tools/lib/clang/include

Unfortunately various headers include headers from other directories and visa/versa, such that having a module.map in each of these directories fails to build, giving me an errors such as:

(file): fatal error: cyclic dependency in module 'platform_include': platform _include -> platform _host_tools -> platform _include

Is there a way to address this without fixing the circular dependencies?

One way that seems to work is to put it all in one module map, at the (platform) level, with relative paths in the header directives.  It appears the compiler will walk up the directories until it finds the module.map file, right?

Regarding the #include to module mechanism, can I assume the compiler matches the module even if the path given in the #include doesn't match the path in the "header" directives in the module.map file, but does refer to the same absolute file?  I.e. the #include references "stdio.h", and a "-I(platform)/target/include" option is given to the compiler, but the (platform)/module.map "header" directive references "target/include/stdio.h".

I have a test bed that includes over 400 stub files that just #include one header, and a makefile to build them.  As a rough performance test, with or without the -fmodules option, they all compile okay in a clean make, but the -fmodules version is about 15% slower (in a run after the modules are compiled).  (Note that I have the compiler output using -emit-llvm because I'm coercing it to think it's a ps4 compiler, since our version doesn't have modules support yet, and the .o output seems to be broken for x86_64.)  I heard others got better performance, but I don't know how it's measured.  Any thoughts?

Thanks.

-John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131014/2d2aa9b0/attachment.html>