Date: Fri, 10 Jun 2022 15:52:20 +0000
[Ben]
> Minor point: per configuration
Correct.
> My understanding wasn't so much the performance, but the implementation
> complexity.
I believe there was lot of conjectures of those nature, yes. I suspect some of us (including me) just need to find the precious time to turn the ideas of feasibility and affordability into running code so everyone can check.
I wouldn't want us to operate under fear, uncertainty, and doubt.
-- Gaby
-----Original Message-----
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Ben Boeckel via SG15
Sent: Friday, June 10, 2022 7:21 AM
To: Daniel Ruoso via SG15 <sg15_at_[hidden]>
Cc: Ben Boeckel <ben.boeckel_at_[hidden]>
Subject: Re: [SG15] Header units and dependency scanning
On Fri, Jun 10, 2022 at 09:33:56 -0400, Daniel Ruoso via SG15 wrote:
> This brings us to another point that has been discussed a few times
> (including an sg15 telecon last year), which is whether or not we
> expect header units to be translated only once, or for it to be
> dependent on the preprocessor arguments of the translation unit
> importing them.
>
> I, personally, am in the camp that header units should be translated
> only once in the project, regardless of the preprocessor arguments
Minor point: per configuration (for single build trees that can handle
building both "release" and "debug" binaries in one build DAG.
I'm of the opinion that this is analogous to "every TU using a header
needs to see a coherent set of declarations" that is already in effect.
Headers configured by defines (Boost PP, C and system headers with their
`_GNU_SOURCE` and friends, etc.) are just not importable IMO.
The alternative is something like (user -> used):
A -> B -> C
If B and C have importable headers, we need to scan C with B's `-D` flag
set and for A's `-D` flag set. Which means we are scanning:
A, B, B_A, C, C_B, C_A
where `X_Y` means "scan X as seen by Y". This only gets worse as the
tree gets deeper if we add a new importable-header-providing dep to C:
A -> B -> C -> D
means scanning:
A, B, B_A, C, C_B, C_A, D, D_C, D_B, D_A
Per-source defines and flags make this even worse because you need to
scan per TU that sees the importable header set.
> used in the translation unit importing it (and this was the consensus
> we had in the sg15 meeting at the time).
IIRC, there was implementation worries about such things.
> It seems the consequence is that the compiler needs to be given not
> only the list of header units and which files they point to for the
> dependency scanning pass, but it also needs the instructions on how to
> preprocess those header units.
>
> I also agree that this seems to be the only reasonable way to implement this.
>
> > But this has potential scalability issues. The most recent
> > thread on this top starts here:
>
> I don't know if I would call it a scalability issue, because it's not
> significantly more expensive than the source inclusion. The compiler
My understanding wasn't so much the performance, but the implementation
complexity.
> just needs to create a new preprocessor state before starting to
> preprocess the imported header. There's no requirement that a full bmi
> be produced at that time, it just needs to know the resulting macros
> after phase 4.
--Ben
_______________________________________________
SG15 mailing list
SG15_at_[hidden]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C6033bdba62154d2aefe408da4aec53cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637904676138982758%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iLfjplRYeW%2BueWPvevlY2MyDju1%2BoVXuNNPTEEywF1E%3D&reserved=0
> Minor point: per configuration
Correct.
> My understanding wasn't so much the performance, but the implementation
> complexity.
I believe there was lot of conjectures of those nature, yes. I suspect some of us (including me) just need to find the precious time to turn the ideas of feasibility and affordability into running code so everyone can check.
I wouldn't want us to operate under fear, uncertainty, and doubt.
-- Gaby
-----Original Message-----
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Ben Boeckel via SG15
Sent: Friday, June 10, 2022 7:21 AM
To: Daniel Ruoso via SG15 <sg15_at_[hidden]>
Cc: Ben Boeckel <ben.boeckel_at_[hidden]>
Subject: Re: [SG15] Header units and dependency scanning
On Fri, Jun 10, 2022 at 09:33:56 -0400, Daniel Ruoso via SG15 wrote:
> This brings us to another point that has been discussed a few times
> (including an sg15 telecon last year), which is whether or not we
> expect header units to be translated only once, or for it to be
> dependent on the preprocessor arguments of the translation unit
> importing them.
>
> I, personally, am in the camp that header units should be translated
> only once in the project, regardless of the preprocessor arguments
Minor point: per configuration (for single build trees that can handle
building both "release" and "debug" binaries in one build DAG.
I'm of the opinion that this is analogous to "every TU using a header
needs to see a coherent set of declarations" that is already in effect.
Headers configured by defines (Boost PP, C and system headers with their
`_GNU_SOURCE` and friends, etc.) are just not importable IMO.
The alternative is something like (user -> used):
A -> B -> C
If B and C have importable headers, we need to scan C with B's `-D` flag
set and for A's `-D` flag set. Which means we are scanning:
A, B, B_A, C, C_B, C_A
where `X_Y` means "scan X as seen by Y". This only gets worse as the
tree gets deeper if we add a new importable-header-providing dep to C:
A -> B -> C -> D
means scanning:
A, B, B_A, C, C_B, C_A, D, D_C, D_B, D_A
Per-source defines and flags make this even worse because you need to
scan per TU that sees the importable header set.
> used in the translation unit importing it (and this was the consensus
> we had in the sg15 meeting at the time).
IIRC, there was implementation worries about such things.
> It seems the consequence is that the compiler needs to be given not
> only the list of header units and which files they point to for the
> dependency scanning pass, but it also needs the instructions on how to
> preprocess those header units.
>
> I also agree that this seems to be the only reasonable way to implement this.
>
> > But this has potential scalability issues. The most recent
> > thread on this top starts here:
>
> I don't know if I would call it a scalability issue, because it's not
> significantly more expensive than the source inclusion. The compiler
My understanding wasn't so much the performance, but the implementation
complexity.
> just needs to create a new preprocessor state before starting to
> preprocess the imported header. There's no requirement that a full bmi
> be produced at that time, it just needs to know the resulting macros
> after phase 4.
--Ben
_______________________________________________
SG15 mailing list
SG15_at_[hidden]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C6033bdba62154d2aefe408da4aec53cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637904676138982758%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iLfjplRYeW%2BueWPvevlY2MyDju1%2BoVXuNNPTEEywF1E%3D&reserved=0
Received on 2022-06-10 15:52:22