[clang] [clang-tools-extra] [clang][modules] Serialize `CodeGenOptions` (PR #146422)

Chuanqi Xu via cfe-commits cfe-commits at lists.llvm.org
Tue Jul 1 19:09:19 PDT 2025


ChuanqiXu9 wrote:

> > How does this patch handle consistency issue? e.g., What if `a.pcm` is compiled with `-O0` but the consumer is compiled with `-O1`? I hope we won't break such things.
> 
> All `Optimize`, `OptimizeSize` and `NoInlineDefine` were `COMPATIBLE_LANGOPT` in `LangOptions`, so I turned their corresponding `CodeGenOptions` into `COMPATIBLE_VALUE_CODEGENOPT` and implemented the `ASTReader` checks the same way: to only fail on mismatch when `!AllowCompatibleDifferences`, which is off by default for explicit PCMs. For implicit PCMs, I made this patch an NFC again by including them in the context hash (only _benign_ `LangOptions` are excluded from that).
> 
> All this to say that with explicit modules, we get the same behavior of being able to reuse PCMs across TUs with different optimization levels, and for implicit modules, we get the same behavior of using a different context hash.

Understood. My concern is, there are many other CodeGenOpts. And if we model them as incompatible default, it will be a breaking change for existing users. We don't like breaking change. How do you feel about to emit a warning so that the end users can have a chance to escape?

https://github.com/llvm/llvm-project/pull/146422


More information about the cfe-commits mailing list