[clang] [C++20] [Modules] Introduce thin BMI (PR #71622)
mathstuf wrote: It was suggested to avoid "thin" and "fat" terminology (I started using it with LTO as a precedent for the terms), but I suppose something more descriptive could be selected. https://github.com/llvm/llvm-project/pull/71622 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++20] [Modules] Introduce thin BMI (PR #71622)
mathstuf wrote: I'll also note that my prior usage was in reference to embedding transitive BMI references in the BMI, not about including function definitions. https://github.com/llvm/llvm-project/pull/71622 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++20] [Modules] Introduce thin BMI (PR #71622)
mathstuf wrote: > Since there is no meaningful review opinions here, let's continue it in a new > and clean PR: https://github.com/llvm/llvm-project/pull/75894 Note that this leaves behind all who have hit "Subscribe" on this PR to keep tabs on things (I wish Github provided a way to mark-as-duplicate and merge the subscriber list). All of the references to this PR are now confused as well. What benefit does a "clean" PR provide? https://github.com/llvm/llvm-project/pull/71622 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++20] [Modules] Introduce thin BMI (PR #71622)
mathstuf wrote: > Sorry for that. But I think it may not be a big deal since people who still > want to take an eye this can made it by clicking two times simply. The timing is also unfortunate as some may have already gone on vacation and will miss updates until they return. Anyways, what's done is done. > The more the comments are, the more confused readers get. Generally a cleaner > PR is not suggested since it lost the context. It is unfortunate that Github sucks so much at rendering discussions (e.g., GItLab's threads that can be resolved makes it easy to collapse down finished things), There is the "mark as off-topic" strategy that I've seen used before, but that is also conflating the desire to hide things with spam control. In the future I would suggest mentioning those who have participated in the prior PR directly so that there's no gap in email/notification coverage. https://github.com/llvm/llvm-project/pull/71622 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][modules] Print library module manifest path. (PR #76451)
@@ -2164,6 +2164,12 @@ bool Driver::HandleImmediateArgs(const Compilation &C) {
return false;
}
+ if (C.getArgs().hasArg(options::OPT_print_library_module_manifest_path)) {
+llvm::outs() << "module: ="
mathstuf wrote:
I'd like there to be some distinction between "modules not present because
Clang was built without them" and "modules not present but expected to be
there" (maybe distro packagers split things and the modules package is
missing?).
https://github.com/llvm/llvm-project/pull/76451
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][modules] Print library module manifest path. (PR #76451)
@@ -2164,6 +2164,12 @@ bool Driver::HandleImmediateArgs(const Compilation &C) {
return false;
}
+ if (C.getArgs().hasArg(options::OPT_print_library_module_manifest_path)) {
+llvm::outs() << "module: ="
mathstuf wrote:
I suppose that's good enough; we also don't get reasons why `-stdlib=libstdc++`
fails due to non-install either.
https://github.com/llvm/llvm-project/pull/76451
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C++20] [Modules] Introduce a tool 'clang-named-modules-querier' and two plugins 'ClangGetUsedFilesFromModulesPlugin' and 'ClangGetDeclsInModulesPlugin' (PR #72956)
mathstuf wrote: > ClangGetUsedFilesFromModulesPlugin This has a hole where if a currently-unused file is not listed, but it is changed in such a way that it now matters (e.g., it changes include order, adds/removes includes, etc.), we need to recompile consumers. > what happens if someone adds an overload, or other interesting name > resolution to the module? We would need to do (at least) one of: - track considered-but-discarded decls (e.g., if something SFINAE'd away now matters because of a new decl); - track "new" decls since the last compile (not sure how the state tracking works here though) and recompile if any show up > "col": 12, > "kind": "Function", > "line": 3, So we change the decl hash if a comment adds a line? That seems like low-hanging fruit to me. Can we enumerate decls and use an index instead? That depends on preprocessor state though, so may be hard to externally verify… https://github.com/llvm/llvm-project/pull/72956 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: How can Autoconf help with the transition to stricter compilation defaults?
On Tue, Nov 15, 2022 at 15:09:19 -0800, Paul Eggert wrote: > This may be a hack, but it's a *good* hack. It's likely to fix > real-world bugs that would be caused if Clang becomes overly pedantic by > default here. And the probability of introducing real-world bugs is > essentially zero. FWIW, CMake uses the same signature for detecting whether a function exists or not: https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/CheckFunctionExists.c It's also been like this (without the `void`) for 20 years; the `void` argument was added 6 years ago: https://gitlab.kitware.com/cmake/cmake/-/commits/master/Modules/CheckFunctionExists.c --Ben ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [clangd] [C++20] [Modules] Introduce initial support for C++20 Modules (PR #66462)
@@ -45,6 +45,10 @@ class GlobalCompilationDatabase {
return std::nullopt;
}
+ virtual std::vector getAllFilesInProjectOf(PathRef File) const {
mathstuf wrote:
`compile_commands.json` probably isn't the best place for it as it cannot be
filled out at the same time (e.g., CMake knows the compile commands once it
generates; it does *not* know the relevant module information until the build
happens and updating the database would be a huge bottleneck).
I have a prototype (that needs some more work) that outlines such a
`module_commands.json`-like file in [this CMake
branch](https://gitlab.kitware.com/ben.boeckel/cmake/-/commits/module-cdb). Of
note that doesn't work:
- flags is not filled out; and
- the commands that merge the per-target databases into a top-level one does
not work.
https://github.com/llvm/llvm-project/pull/66462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [clangd] [C++20] [Modules] Introduce initial support for C++20 Modules (PR #66462)
@@ -45,6 +45,10 @@ class GlobalCompilationDatabase {
return std::nullopt;
}
+ virtual std::vector getAllFilesInProjectOf(PathRef File) const {
mathstuf wrote:
Probably easiest to see it by the writer code
[here](https://gitlab.kitware.com/ben.boeckel/cmake/-/commit/9866da328034fbb3a0e96f5cca81e913c0ab8678#b94b7587efb540b6ad866ae5620492d78f6cff24_0_23).
Basically, it is:
```json
{
"version": 1,
"revision": 0,
"module_sets": [
{
"name": "unique name of module set",
"visible_module_sets": [
"module sets",
"which can satisfy",
"required modules within this module set",
],
"modules": [
"work-directory": "/path/to/working/directory",
"source": "path/to/source/file",
"name": "name.of.provided.module",
"private": false,
"requires": [
"list",
"of",
"required",
"modulest"
],
"flag_sets": [
"-fstandalone-flag",
["-fflag", "with-arg"],
]
]
}
]
}
```
The semantics are:
- module sets may refer to other module sets named in order to satisfy their
required modules;
- however, private modules in other module sets are not usable;
- `work-directory` is optional;
- `private` defaults to `false`;
- flag sets need to be used to compile the BMI in question (Daniel Ruoso's
"local preprocessor arguments");
- flags may be deduplicated/merged by top-level identities.
https://github.com/llvm/llvm-project/pull/66462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [clangd] [C++20] [Modules] Introduce initial support for C++20 Modules (PR #66462)
https://github.com/mathstuf edited https://github.com/llvm/llvm-project/pull/66462 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [clangd] [C++20] [Modules] Introduce initial support for C++20 Modules (PR #66462)
https://github.com/mathstuf edited https://github.com/llvm/llvm-project/pull/66462 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [clangd] [C++20] [Modules] Introduce initial support for C++20 Modules (PR #66462)
https://github.com/mathstuf edited https://github.com/llvm/llvm-project/pull/66462 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Transitive Change
+-
+
+This section is primarily for build system vendors. For end compiler users,
+if you don't want to read it all, this is helpful to reduce recompilations
+We encourage build system vendors and end users try this out and bring
feedbacks
+
+Before Clang 19, a change in BMI of any (transitive) dependency would case the
+outputs of the BMI to change. Starting with Clang 19, changes to non-direct
+dependencies should not directly affect the output BMI, unless they affect the
+results of the compilations. We expect that there are many more opportunities
+for this optimization than we currently have realized and would appreaciate
+feedback about missed optimization opportunities. For example,
+
+.. code-block:: c++
+
+ // m-partA.cppm
+ export module m:partA;
+
+ // m-partB.cppm
+ export module m:partB;
+ export int getB() { return 44; }
+
+ // m.cppm
+ export module m;
+ export import :partA;
+ export import :partB;
+
+ // useBOnly.cppm
+ export module useBOnly;
+ import m;
+ export int B() {
+return getB();
+ }
+
+ // Use.cc
+ import useBOnly;
+ int get() {
+return B();
+ }
+
+To compile the project (for brevity, some commands are omitted.):
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+If the interface of ``m-partA.cppm`` is changed to:
+
+.. code-block:: c++
+
+ // m-partA.v1.cppm
+ export module m:partA;
+ export int getA() { return 43; }
+
+and the BMI for ``useBOnly`` is recompiled as in:
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+then the contents of ``useBOnly.pcm`` remain unchanged.
+Consequently, if the build system only bases recompilation decisions on
directly imported modules,
+it becomes possible to skip the recompilation of ``Use.cc``.
+It should be fine because the altered interfaces do not affect ``Use.cc`` in
any way;
+there are no transitive changes.
+
+When clang generates a BMI, it records the hash values of all potentially
contributory BMIs
+for the BMI being produced. This ensures that build systems are not required
to consider
+transitively imported modules when deciding whether to recompile.
+
+What is considered to be a potential contributory BMIs is currently
unspecified.
+However, it is a severe bug for a BMI to remain unchanged following an
observable change
+that affects its consumers.
+
+We recommend that build systems support this feature as a configurable option
so that users
+can go back to the transitive change mode safely at any time.
mathstuf wrote:
Ok, so what do I do differently? AFAIK, CMake is relying on the compiler's
`-MF` reporting mechanisms here.
https://github.com/llvm/llvm-project/pull/96453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Transitive Change
+-
+
+This section is primarily for build system vendors. For end compiler users,
+if you don't want to read it all, this is helpful to reduce recompilations
+We encourage build system vendors and end users try this out and bring
feedbacks
+
+Before Clang 19, a change in BMI of any (transitive) dependency would case the
+outputs of the BMI to change. Starting with Clang 19, changes to non-direct
+dependencies should not directly affect the output BMI, unless they affect the
+results of the compilations. We expect that there are many more opportunities
+for this optimization than we currently have realized and would appreaciate
+feedback about missed optimization opportunities. For example,
+
+.. code-block:: c++
+
+ // m-partA.cppm
+ export module m:partA;
+
+ // m-partB.cppm
+ export module m:partB;
+ export int getB() { return 44; }
+
+ // m.cppm
+ export module m;
+ export import :partA;
+ export import :partB;
+
+ // useBOnly.cppm
+ export module useBOnly;
+ import m;
+ export int B() {
+return getB();
+ }
+
+ // Use.cc
+ import useBOnly;
+ int get() {
+return B();
+ }
+
+To compile the project (for brevity, some commands are omitted.):
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+If the interface of ``m-partA.cppm`` is changed to:
+
+.. code-block:: c++
+
+ // m-partA.v1.cppm
+ export module m:partA;
+ export int getA() { return 43; }
+
+and the BMI for ``useBOnly`` is recompiled as in:
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+then the contents of ``useBOnly.pcm`` remain unchanged.
+Consequently, if the build system only bases recompilation decisions on
directly imported modules,
+it becomes possible to skip the recompilation of ``Use.cc``.
+It should be fine because the altered interfaces do not affect ``Use.cc`` in
any way;
+there are no transitive changes.
+
+When clang generates a BMI, it records the hash values of all potentially
contributory BMIs
+for the BMI being produced. This ensures that build systems are not required
to consider
+transitively imported modules when deciding whether to recompile.
+
+What is considered to be a potential contributory BMIs is currently
unspecified.
+However, it is a severe bug for a BMI to remain unchanged following an
observable change
+that affects its consumers.
+
+We recommend that build systems support this feature as a configurable option
so that users
+can go back to the transitive change mode safely at any time.
mathstuf wrote:
Ah, ok.
FWIW, I was thinking that even `a.pcm` would get reported in `-MF` for your
example and elided if it didn't contribute. As for the `restat = 1` with a
swap, yes, that is build-system side. I think some docs saying something like:
```md
Build systems may utilize this optimization by doing an update-if-changed
operation to the BMI
that is consumed from the BMI that is output by the compiler.
```
https://github.com/llvm/llvm-project/pull/96453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Fix missing installed header (PR #95979)
mathstuf wrote: > Nice find. That's kind of horrifying. Indeed. CMake's old "guess the extension" behavior was always a…fun thing to deal with. Alas, this emergent behavior was unknown at the time and a straight fix is likely to break other projects :( . Plus it's not likely we'll get patched releases for the past 18 releases. Luckily, there is a fix here. We'll get this in the test suite and properly nailed down though; hopefully we can detect this behavior so that other projects can discover such instances as well. https://github.com/llvm/llvm-project/pull/95979 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Transitive Change
+-
+
+This section is primarily for build system vendors. For end compiler users,
+if you don't want to read it all, this is helpful to reduce recompilations
+We encourage build system vendors and end users try this out and bring
feedbacks
+
+Before Clang 19, a change in BMI of any (transitive) dependency would case the
+outputs of the BMI to change. Starting with Clang 19, changes to non-direct
+dependencies should not directly affect the output BMI, unless they affect the
+results of the compilations. We expect that there are many more opportunities
+for this optimization than we currently have realized and would appreaciate
+feedback about missed optimization opportunities. For example,
+
+.. code-block:: c++
+
+ // m-partA.cppm
+ export module m:partA;
+
+ // m-partB.cppm
+ export module m:partB;
+ export int getB() { return 44; }
+
+ // m.cppm
+ export module m;
+ export import :partA;
+ export import :partB;
+
+ // useBOnly.cppm
+ export module useBOnly;
+ import m;
+ export int B() {
+return getB();
+ }
+
+ // Use.cc
+ import useBOnly;
+ int get() {
+return B();
+ }
+
+To compile the project (for brevity, some commands are omitted.):
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+If the interface of ``m-partA.cppm`` is changed to:
+
+.. code-block:: c++
+
+ // m-partA.v1.cppm
+ export module m:partA;
+ export int getA() { return 43; }
+
+and the BMI for ``useBOnly`` is recompiled as in:
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+then the contents of ``useBOnly.pcm`` remain unchanged.
+Consequently, if the build system only bases recompilation decisions on
directly imported modules,
+it becomes possible to skip the recompilation of ``Use.cc``.
+It should be fine because the altered interfaces do not affect ``Use.cc`` in
any way;
+there are no transitive changes.
+
+When clang generates a BMI, it records the hash values of all potentially
contributory BMIs
+for the BMI being produced. This ensures that build systems are not required
to consider
+transitively imported modules when deciding whether to recompile.
+
+What is considered to be a potential contributory BMIs is currently
unspecified.
+However, it is a severe bug for a BMI to remain unchanged following an
observable change
+that affects its consumers.
+
+We recommend that build systems support this feature as a configurable option
so that users
+can go back to the transitive change mode safely at any time.
+
+Interactions with Reduced BMI
+~
+
+With reduced BMI, the no transitive change feature can be more powerful. For
example,
+
+.. code-block:: c++
+
+ // A.cppm
+ export module A;
+ export int a() { return 44; }
+
+ // B.cppm
+ export module B;
+ import A;
+ export int b() { return a(); }
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 A.cppm -c -fmodule-output=A.pcm
-fexperimental-modules-reduced-bmi -o A.o
+ $ clang++ -std=c++20 B.cppm -c -fmodule-output=B.pcm
-fexperimental-modules-reduced-bmi -o B.o -fmodule-file=A=A.pcm
+ $md5sum B.pcm
mathstuf wrote:
```suggestion
$ md5sum B.pcm
```
https://github.com/llvm/llvm-project/pull/96453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Transitive Change
+-
+
+This section is primarily for build system vendors. For end compiler users,
+if you don't want to read it all, this is helpful to reduce recompilations
+We encourage build system vendors and end users try this out and bring
feedbacks
+
+Before Clang 19, a change in BMI of any (transitive) dependency would case the
+outputs of the BMI to change. Starting with Clang 19, changes to non-direct
+dependencies should not directly affect the output BMI, unless they affect the
+results of the compilations. We expect that there are many more opportunities
+for this optimization than we currently have realized and would appreaciate
+feedback about missed optimization opportunities. For example,
+
+.. code-block:: c++
+
+ // m-partA.cppm
+ export module m:partA;
+
+ // m-partB.cppm
+ export module m:partB;
+ export int getB() { return 44; }
+
+ // m.cppm
+ export module m;
+ export import :partA;
+ export import :partB;
+
+ // useBOnly.cppm
+ export module useBOnly;
+ import m;
+ export int B() {
+return getB();
+ }
+
+ // Use.cc
+ import useBOnly;
+ int get() {
+return B();
+ }
+
+To compile the project (for brevity, some commands are omitted.):
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+If the interface of ``m-partA.cppm`` is changed to:
+
+.. code-block:: c++
+
+ // m-partA.v1.cppm
+ export module m:partA;
+ export int getA() { return 43; }
+
+and the BMI for ``useBOnly`` is recompiled as in:
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+then the contents of ``useBOnly.pcm`` remain unchanged.
+Consequently, if the build system only bases recompilation decisions on
directly imported modules,
+it becomes possible to skip the recompilation of ``Use.cc``.
+It should be fine because the altered interfaces do not affect ``Use.cc`` in
any way;
+there are no transitive changes.
+
+When clang generates a BMI, it records the hash values of all potentially
contributory BMIs
mathstuf wrote:
```suggestion
When Clang generates a BMI, it records the hash values of all potentially
contributory BMIs
```
or
```suggestion
When ``clang`` generates a BMI, it records the hash values of all potentially
contributory BMIs
```
https://github.com/llvm/llvm-project/pull/96453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Transitive Change
+-
+
+This section is primarily for build system vendors. For end compiler users,
+if you don't want to read it all, this is helpful to reduce recompilations
+We encourage build system vendors and end users try this out and bring
feedbacks
+
+Before Clang 19, a change in BMI of any (transitive) dependency would case the
+outputs of the BMI to change. Starting with Clang 19, changes to non-direct
+dependencies should not directly affect the output BMI, unless they affect the
+results of the compilations. We expect that there are many more opportunities
+for this optimization than we currently have realized and would appreaciate
+feedback about missed optimization opportunities. For example,
+
+.. code-block:: c++
+
+ // m-partA.cppm
+ export module m:partA;
+
+ // m-partB.cppm
+ export module m:partB;
+ export int getB() { return 44; }
+
+ // m.cppm
+ export module m;
+ export import :partA;
+ export import :partB;
+
+ // useBOnly.cppm
+ export module useBOnly;
+ import m;
+ export int B() {
+return getB();
+ }
+
+ // Use.cc
+ import useBOnly;
+ int get() {
+return B();
+ }
+
+To compile the project (for brevity, some commands are omitted.):
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+If the interface of ``m-partA.cppm`` is changed to:
+
+.. code-block:: c++
+
+ // m-partA.v1.cppm
+ export module m:partA;
+ export int getA() { return 43; }
+
+and the BMI for ``useBOnly`` is recompiled as in:
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+then the contents of ``useBOnly.pcm`` remain unchanged.
+Consequently, if the build system only bases recompilation decisions on
directly imported modules,
+it becomes possible to skip the recompilation of ``Use.cc``.
+It should be fine because the altered interfaces do not affect ``Use.cc`` in
any way;
+there are no transitive changes.
+
+When clang generates a BMI, it records the hash values of all potentially
contributory BMIs
+for the BMI being produced. This ensures that build systems are not required
to consider
+transitively imported modules when deciding whether to recompile.
+
+What is considered to be a potential contributory BMIs is currently
unspecified.
+However, it is a severe bug for a BMI to remain unchanged following an
observable change
+that affects its consumers.
+
+We recommend that build systems support this feature as a configurable option
so that users
+can go back to the transitive change mode safely at any time.
mathstuf wrote:
How does this happen? Is something missing in the example commands? They look
"normal" to me.
https://github.com/llvm/llvm-project/pull/96453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as
of Clang 19.x is:
comes, the term BMI will refer to the Reduced BMI and the Full BMI will only
be meaningful to build systems which elect to support two-phase compilation.
+Experimental No Transitive Change
+-
+
+This section is primarily for build system vendors. For end compiler users,
+if you don't want to read it all, this is helpful to reduce recompilations
+We encourage build system vendors and end users try this out and bring
feedbacks
+
+Before Clang 19, a change in BMI of any (transitive) dependency would case the
+outputs of the BMI to change. Starting with Clang 19, changes to non-direct
+dependencies should not directly affect the output BMI, unless they affect the
+results of the compilations. We expect that there are many more opportunities
+for this optimization than we currently have realized and would appreaciate
+feedback about missed optimization opportunities. For example,
+
+.. code-block:: c++
+
+ // m-partA.cppm
+ export module m:partA;
+
+ // m-partB.cppm
+ export module m:partB;
+ export int getB() { return 44; }
+
+ // m.cppm
+ export module m;
+ export import :partA;
+ export import :partB;
+
+ // useBOnly.cppm
+ export module useBOnly;
+ import m;
+ export int B() {
+return getB();
+ }
+
+ // Use.cc
+ import useBOnly;
+ int get() {
+return B();
+ }
+
+To compile the project (for brevity, some commands are omitted.):
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+If the interface of ``m-partA.cppm`` is changed to:
+
+.. code-block:: c++
+
+ // m-partA.v1.cppm
+ export module m:partA;
+ export int getA() { return 43; }
+
+and the BMI for ``useBOnly`` is recompiled as in:
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 m-partA.cppm --precompile -o m-partA.pcm
+ $ clang++ -std=c++20 m-partB.cppm --precompile -o m-partB.pcm
+ $ clang++ -std=c++20 m.cppm --precompile -o m.pcm -fprebuilt-module-path=.
+ $ clang++ -std=c++20 useBOnly.cppm --precompile -o useBOnly.pcm
-fprebuilt-module-path=.
+ $ md5sum useBOnly.pcm
+ 07656bf4a6908626795729295f9608da useBOnly.pcm
+
+then the contents of ``useBOnly.pcm`` remain unchanged.
+Consequently, if the build system only bases recompilation decisions on
directly imported modules,
+it becomes possible to skip the recompilation of ``Use.cc``.
+It should be fine because the altered interfaces do not affect ``Use.cc`` in
any way;
+there are no transitive changes.
+
+When clang generates a BMI, it records the hash values of all potentially
contributory BMIs
+for the BMI being produced. This ensures that build systems are not required
to consider
+transitively imported modules when deciding whether to recompile.
+
+What is considered to be a potential contributory BMIs is currently
unspecified.
+However, it is a severe bug for a BMI to remain unchanged following an
observable change
+that affects its consumers.
+
+We recommend that build systems support this feature as a configurable option
so that users
+can go back to the transitive change mode safely at any time.
+
+Interactions with Reduced BMI
+~
+
+With reduced BMI, the no transitive change feature can be more powerful. For
example,
+
+.. code-block:: c++
+
+ // A.cppm
+ export module A;
+ export int a() { return 44; }
+
+ // B.cppm
+ export module B;
+ import A;
+ export int b() { return a(); }
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 A.cppm -c -fmodule-output=A.pcm
-fexperimental-modules-reduced-bmi -o A.o
+ $ clang++ -std=c++20 B.cppm -c -fmodule-output=B.pcm
-fexperimental-modules-reduced-bmi -o B.o -fmodule-file=A=A.pcm
+ $md5sum B.pcm
+ 6c2bd452ca32ab418bf35cd141b060b9 B.pcm
+
+And let's change the implementation for ``A.cppm`` into:
+
+.. code-block:: c++
+
+ export module A;
+ int a_impl() { return 99; }
+ export int a() { return a_impl(); }
+
+and recompile the example:
+
+.. code-block:: console
+
+ $ clang++ -std=c++20 A.cppm -c -fmodule-output=A.pcm
-fexperimental-modules-reduced-bmi -o A.o
+ $ clang++ -std=c++20 B.cppm -c -fmodule-output=B.pcm
-fexperimental-modules-reduced-bmi -o B.o -fmodule-file=A=A.pcm
+ $md5sum B.pcm
mathstuf wrote:
```suggestion
$ md5sum B.pcm
```
https://github.com/llvm/llvm-project/pull/96453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Doc] Update documentation for no-transitive-change (PR #96453)
@@ -652,6 +652,141 @@ in the future. The expected roadmap for Reduced BMIs as of Clang 19.x is: comes, the term BMI will refer to the Reduced BMI and the Full BMI will only be meaningful to build systems which elect to support two-phase compilation. +Experimental No Transitive Change +- + +This section is primarily for build system vendors. For end compiler users, +if you don't want to read it all, this is helpful to reduce recompilations +We encourage build system vendors and end users try this out and bring feedbacks + +Before Clang 19, a change in BMI of any (transitive) dependency would case the mathstuf wrote: ```suggestion Before Clang 19, a change in BMI of any (transitive) dependency would cause the ``` https://github.com/llvm/llvm-project/pull/96453 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Serialization] Downgrade error to warning for inconsistent language flags (PR #117840)
mathstuf wrote: > Really we would have to remove the preprocessor from C++ to be able to get > away from this. :clap: Maybe we can get a magic `-fno-preprocess` flag to say "I use no preprocessor shenanigans" and make always-compatible BMIs? Maybe then we could adapt the Fortran/ASM convention where an uppercase extension means "I need preprocessing" and lowercase doesn't. (tongue lightly in cheek…) https://github.com/llvm/llvm-project/pull/117840 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Fix print module manifest file for macos (PR #122370)
mathstuf wrote: Should this be backported to older supported releases as well? (FWIW, I think so.) https://github.com/llvm/llvm-project/pull/122370 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
