[Mlir-commits] [llvm] [mlir] Shard the public llvm-config.h in multiple files (NFC) (PR #71273)

[Chris B]

llvm-beanz wrote:

> But the impacts seemed obvious to me, let me actually give numbers, it is fairly easily collect them:
> 
> * There are 25 files which uses LLVM_VERSION_*, yet the LLVM_VERSION_ macro impacts all the files which transitively include llvm-config.h (that is ~ all of the project?). So including LLVM_VERSION where it's used will reduce by O(100-1000) the number of compilation commands affected.
> * LLVM_ENABLE_CURL is used in 2 files, but the macro impacts all the files including `llvm-config.h` transitively, so that is again a factor of O(1000) reduction.
> * ... (I can continue to grep, but think it'll be the same for all of these?)
> 
> For example, switching the LLVM_ENABLE_CURL ON/OFF config, on one build config (not including flang/clang) it means 5126 targets to rebuild before, and only 20 after (this is what I observe with `ninja` locally in practice).

Your initial comment referred to caching. If you apply `ccache` or `scache`, both preprocess before determining a cache collision, which means that extremely few things rebuild. With object file caching utilities you don't get penalized for preprocessor defines that aren't used in a given translation unit, so it seems that to me that the benefits would be very small.

This continues to lead me to the conclusion that I'm not convinced this change provides enough benefit to justify complicating our configuration include paradigm. Having a single (or small number) of headers that are autoconf or cmake generated is fairly common, having one header per configuration setting is not something I've ever seen a project do.

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