> On Feb 25, 2015, at 1:34 PM, Richard Smith <[email protected]> wrote: > > On Wed, Feb 25, 2015 at 1:02 PM, Adrian Prantl <[email protected]> wrote: > On Feb 24, 2015, at 6:28 PM, Adrian Prantl <[email protected]> wrote: >> You are correct. I need to remove the use of PCHGenerator from >> ModuleContainerGenerator. >>> On Feb 24, 2015, at 6:11 PM, NAKAMURA Takumi <[email protected]> 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)?
I was able to make PCHGenerator agnostic of the wrapper format, but it is not possible to push the wrapper-awareness out any further than FrontendActions. > 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... Is that a hypothetical scenario or are there any such users out there? I understand there are tools like clang-format/modernize/... which after this change have to link against the LLVM targets in order to generate clang-compatible modules; but are there any non-LLVM compilers that use clang as a frontend? > > 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. > > <before.png> > > 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. That sounds like a good idea; I might also be able to move it into CodeGen itself. > > 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. I agree that it is tightly coupled to CodeGen, but it is also tightly coupled to CompilerInstance, which has its tentacles all over Frontend so it needs to move somewhere to break the cycle. Do you see any specific problems with having CodeGenAction in FrontendTool? thanks for the feedback! adrian > > - 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: > > <after.png> > > I’ll try and implement it this way; hopefully I didn’t miss any other edges > in the graph. > -- adrian > >> >> thanks for noticing! >> -- adrian > > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
