dblaikie added a comment. In D83652#2146732 <https://reviews.llvm.org/D83652#2146732>, @llunak wrote:
> The patch is incomplete, isn't it? It removes DeclIsFromPCHWithObjectFile(), > but it's still called from ASTContext::DeclMustBeEmitted(). The description > also mentions updating of the pch-codegen test, but that's not included. Ah, right you are - arc diff only took the last commit on this branch. I've updated it/used arc correctly to get the whole branch worth of changes. > But assuming this is intended to replace the D48426 > <https://reviews.llvm.org/D48426> functionality with modular codegen, Not quite - it's intended to implement the D48426 <https://reviews.llvm.org/D48426> functionality using an implementation strategy that is closer to modular code generation. Removing the need for the module flag, using the MODULAR_CODEGEN_DECLS list, etc. But only putting the dllexported entities in there (when using only building-pch-with-obj without -fmodules-codegen). The intent is not to change the behavior of D48426 <https://reviews.llvm.org/D48426>, but to simplify the implementation a bit by reducing the divergence between the two features. >> Do either of you know if it'd be practical to move to something more similar >> to .pcm handling, where the pch itself is passed to the compilation, rather >> than homed as a side effect of compiling some other source file? > > Do you mean dropping compatibility with 'cl.exe /Yc'? Yep, that was essentially what I was wondering - since you were proposing a build mode/flags that would not be /Yc compatible, adding an explicit pch build and pch object build step - was wondering if the build system support for that was sufficiently available that it would be practical for users (like Chromium) to migrate to that kind of model and no longer need /Yc compatibility. That would further reduce some of the divergence between the two features (then it'd come down to only a "what entities do we want to home" question - the mechanics of homing them, building their object file, etc, would all be the same). In D83652#2147097 <https://reviews.llvm.org/D83652#2147097>, @hans wrote: > In D83652#2146732 <https://reviews.llvm.org/D83652#2146732>, @llunak wrote: > > > > Do either of you know if it'd be practical to move to something more > > > similar to .pcm handling, where the pch itself is passed to the > > > compilation, rather than homed as a side effect of compiling some other > > > source file? > > > > Do you mean dropping compatibility with 'cl.exe /Yc'? > > > I don't think we can change the interface, because we want cl.exe > compatibility. Fair enough - I guess the only other way to get the cl.exe behavior from the Clang driver using modular codegen-type functionality would be to use 4 steps: - build PCH (with dllexport modular codegen) - build PCH object file using PCH - build source object using PCH - ld -r the two objects together But I guess the added driver complexity isn't worth the simplification inside Clang proper, probably. I guess we already have the "build PCH then use PCH to build object" part so /maybe/ it'd be feasible to extend it in this way. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D83652/new/ https://reviews.llvm.org/D83652 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
