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

[Richard Smith]

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

>
> > On Feb 25, 2015, at 1:34 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> >
> > 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)?
>
> 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
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150225/9b4d4a80/attachment.html>