<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 2, 2015, at 4:42 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com" class="">aprantl@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 25, 2015, at 5:30 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" class="">richard@metafoo.co.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 25, 2015 at 4:25 PM, Adrian Prantl <span dir="ltr" class=""><<a href="mailto:aprantl@apple.com" target="_blank" class="">aprantl@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Feb 25, 2015, at 3:37 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank" class="">richard@metafoo.co.uk</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 25, 2015 at 2:22 PM, Adrian Prantl <span dir="ltr" class=""><<a href="mailto:aprantl@apple.com" target="_blank" class="">aprantl@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br class="">
> On Feb 25, 2015, at 1:34 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank" class="">richard@metafoo.co.uk</a>> wrote:<br class="">
><br class="">
> On Wed, Feb 25, 2015 at 1:02 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank" class="">aprantl@apple.com</a>> wrote:<br class="">
> On Feb 24, 2015, at 6:28 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank" class="">aprantl@apple.com</a>> wrote:<br class="">
>> You are correct. I need to remove the use of PCHGenerator from ModuleContainerGenerator.<br class="">
>>> On Feb 24, 2015, at 6:11 PM, NAKAMURA Takumi <<a href="mailto:geek4civic@gmail.com" target="_blank" class="">geek4civic@gmail.com</a>> wrote:<br class="">
>>> It still has circular dependencies between clangCodeGen and clangFrontend.<br class="">
><br class="">
> After some deliberation, I noticed that there is actually more to be done here in order to resolve the cyclic dependencies.<br class="">
><br class="">
> 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)?<br class="">
<br class="">
</span>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.</blockquote><div class=""><br class=""></div><div class="">"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.</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Challenge accepted, I should be possible: I image that we could introduce a ModuleContainerGeneratorFactory</div></div></div></blockquote><div class=""><br class=""></div><div class="">Maybe the right level of interface is a ModuleProvider, so that CompilerInstance can just say "I want a representation of this Module to be loaded" and not care at all about whether or how that representation is built or stored on disk. (I can imagine distributed build systems that might want some behavior here other than physical files in some file system.)</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Hi Richard,</div><div class=""><br class=""></div><div class="">FYI, here is the patch with an abstract ModuleProvider interface that has one implementation in CodeGen/LLVMModuleProvider.cpp. The interface currently provides only two functions, one that creates an ASTConsumer that wraps a module in container and another function that unwraps a module container. The owner of the ModuleProvider is ModuleLoader, which is the base class of CompilerInstance and ASTUnit. Together with moving CodeGenOptions and BuryPointer into Basic, this made it possible to completely eliminate the dependency from Frontend -> CodeGen. As a bonus, clients are now able to provide alternative implementations of ModuleProvider as outlined above. In order for create something like the aforementioned distributed build system, some more functionality (such as the module cache handling) would need to move from Serialization into ModuleProvider.</div><div class="">The downside of the new approach is that now every tool now explicitly needs to instantiate a ModuleProvider which made writing this patch a little tedious. I’ve been thinking about providing a default argument for the module provider, but that would make it easy to accidentally mix-match incompatible module compilers, so I decided against that.</div><div class=""><br class=""></div><div class="">The diff between this and the previous version is quite large (though mostly mechanical changes) so I wanted to give you a chance to object before I push this in tree again.</div></div></div></div></blockquote><div><br class=""></div>Ping. No objections to threading a ModuleProvider through every CompilerInstance, or haven’t had a chance to look at it so far?</div><div>In the mean time, I was able to simplify the patch some more: Because of abstract ModuleProvider interface, it is of course no longer necessary to shuffle CodeGenOptions, CodeGenAction, and BuryPointer around and they can stay where they are — which was part of the point of the whole exercise.</div><div><br class=""></div><div>thanks,</div><div>adrian</div><div><div><br class=""></div><div></div></div></body></html>