[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]

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