On Wed, Feb 25, 2015 at 2:22 PM, Adrian Prantl <[email protected]> wrote:
> > > 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. "not possible" is quite a strong claim to make. It would seem possible for FrontendTool to hand the CompilerInstance or Action a collection of callbacks for creating / importing module file data. > 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 don't have concrete knowledge of anyone doing this today, but enough people have asked about this that it's not unreasonable to think that someone might have actually done it. > 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? I think there are, but I'm not sure if they all do this by converting LLVM IR to their own IR or whether some of them go straight from a Clang AST. Whether or not such compilers exist today, we should try to avoid creating barriers for people who want to do this in the future. > 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? > No specific problem, only a general malaise: we deliberately isolate all the parts of Clang that touch LLVM IR in lib/CodeGen; this change would violate that notional encapsulation. 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
