[PATCH] D158709: [Headers][Modules] Make separate headers for the stdarg.h and stddef.h pieces so that they can be modularized
Aaron Ballman via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Aug 28 06:54:29 PDT 2023
aaron.ballman added a comment.
In D158709#4617783 <https://reviews.llvm.org/D158709#4617783>, @iana wrote:
> In D158709#4617295 <https://reviews.llvm.org/D158709#4617295>, @aaron.ballman wrote:
>
>> I'm a bit concerned about the impact on (non-modules) build time performance. This splits stddef.h and stdarg.h into needing to open 14 different files instead of 2. Hopefully that's not a lot of overhead, but given that stddef.h is included in approximately every TU and that sometimes external forces cause files to be slow to open (network drives, AV software, etc), I think we should be cautious and measure the impact. I also really do not like how poorly this scales -- the fact that this is only needed for these two files helps a bit, but this is a lot of C++-specific hoops to jump through for C standard library headers.
>
> This is in support of clang modules, not C++ modules.
Ah, good to know, thank you!
> The plan is to make modules like this.
>
> module _Builtin_stddef [system] {
> textual header "stddef.h"
>
> explicit module max_align_t {
> header "__stddef_max_align_t.h"
> export *
> }
>
> explicit module null {
> header "__stddef_null.h"
> export *
> }
> ...
> }
>
> I do agree it's a bit of a file explosion, but I can't really think of any better alternatives. It's tough to measure build time performance impact. If you have a slow enough file system (and the fs on our builders at Apple is quite slow), and you aren't using modules or pch's, and you have quite a lot of source files, then possibly this would be noticeable? I still don't know what we could really do about it besides have `#if !__has_feature(modules)` and inline the contents in that case. That seems like a maintenance headache and a half though. I would hope that most sizable projects either use clang modules or pch's?
Yeah, measuring file system impacts is always tricky. :-( The reason I'm concerned is actually because a fair number of projects explicitly don't use PCH or Clang modules (or C++ modules), especially in C. Because of how fast compilations go in C, it's possible that the extra filesystem overhead really will be noticeable by users. However, I also can't think of a way around this in code...
At a high-level (not just for this patch, but for the entire series): is this need specific to your downstream or is this a more general need? e.g., should this complexity be kept downstream until we've got a second platform needing it?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D158709/new/
https://reviews.llvm.org/D158709
More information about the cfe-commits
mailing list