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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
