r230423 - Wrap clang module files in a Mach-O, ELF, or COFF container.

[Richard Smith]

On Wed, Feb 25, 2015 at 1:02 PM, Adrian Prantl <aprantl at apple.com> wrote:

> On Feb 24, 2015, at 6:28 PM, Adrian Prantl <aprantl at apple.com> wrote:
>
> You are correct. I need to remove the use of PCHGenerator from
> ModuleContainerGenerator.
>
> On Feb 24, 2015, at 6:11 PM, NAKAMURA Takumi <geek4civic at gmail.com> wrote:
> It still has circular dependencies between clangCodeGen and clangFrontend.
>
>
> After some deliberation, I noticed that there is actually more to be done
> here in order to resolve the cyclic dependencies.
>

Well, it makes sense that there would be problems here, since you're
coupling our lex-only / parse-only modes to IR generation. I wonder if it
would be possible to entirely isolate Frontend from knowledge of the module
wrapper format (putting it in FrontendTool instead)? If not, I don't think
we have any other option than to grow a Frontend->CodeGen dependency, which
in turn will be terrible for people who want to use our frontend with a
different backend...

Here is a graph of (a simplified subset of) the dependencies after this
> commit:
> - Pretty much all of CodeGen depends on CodeGenOptions, which is currently
> part of Frontend.
> - BackendUtil and CodeGenAction depend on both CodeGen and Frontend.
> - CodeGenModuleContainer introduces a cyclic dependency between Frontend
> and CodeGen.
>
>
> The above cycle can be resolved by reversing the CodeGen->Frontend
> dependency and splitting out the common dependencies CodeGenOptions and
> frontend::utils::BuryPointer into a separate library that I’m calling
> FrontendSupport for lack of a better name.
>

The right place for CodeGenOptions is probably Basic, alongside
LangOptions, TargetOptions, CommentOptions, etc.

After this, the only remaining CodeGen->Frontend dependencies are
> CodeGen/BackendUtil.cpp and CodeGen/CodeGenAction.cpp:
> - CodeGenAction looks like it could safely be moved into FrontendTool,
> which is its only user.
>

I don't think that's necessarily a good idea: CodeGenAction is tightly
coupled to CodeGen and only very loosely coupled to the frontend.

- BackendUtil can stay were it is, it is needed by CodeGenAction and (via
> CodeGenModuleContainer) by Frontend. The dependency on Frontend can be
> eliminated by splitting BuryPointer out from Utils.
> The new picture then looks like this:
>
>
> I’ll try and implement it this way; hopefully I didn’t miss any other
> edges in the graph.
> -- adrian
>
>
> thanks for noticing!
> -- adrian
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150225/cbd2f0e4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: before.png
Type: image/png
Size: 92586 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150225/cbd2f0e4/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: after.png
Type: image/png
Size: 96787 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150225/cbd2f0e4/attachment-0001.png>