Date: Wed, 19 Jun 2019 18:33:15 -0700
On Tue, Jun 18, 2019 at 9:22 AM Gabriel Dos Reis via SG15 <
sg15_at_[hidden]> wrote:
> | -----Original Message-----
> | From: Modules <modules-bounces_at_[hidden]> On Behalf Of Matthew
> | Woehlke
> | Sent: Tuesday, June 18, 2019 9:14 AM
> | To: Corentin <corentin.jabot_at_[hidden]>; modules_at_[hidden]
> | Cc: sg15_at_[hidden]; Olga Arkhipova <olgaark_at_[hidden]>
> | Subject: Re: [isocpp-modules] [SG15] Reuse of the built modules (BMI)
> paper
> |
> | On 18/06/2019 02.52, Corentin wrote:
> | > Is there anything as "slightly different compilation options" ? Given
> that
> | > almost everything can be observed from the source code, a compiler
> | should
> | > be conservative with what it considers "reusable".
> | > Let's not sacrifice correctness and reliability for the sake of
> compilation
> | > times (even if that appears to be often the case regardless of modules)
> |
> | Just because something is *observable* doesn't mean that it *is*
> | observed (or that it produces a change in the BMI even if it is). I
> | would guess that >90% of the time there are very few compile options
> | that actually affect the BMI.
> |
> | In fact, I would question if e.g. debugging information and optimization
> | levels affect the BMI. They affect the *object code*, sure enough, but
> | it seems like they *shouldn't* affect the BMI...
>
> You are right spot on for the case of MSVC. I wouldn't be surprised if
> that was the case of Clang too. I am less familiar with how GCC does
> things these days.
>
Yes, that's generally right for Clang too. We unfortunately expose some
details of optimization flags to the source code (eg, via the __OPTIMIZE__
macro), so it is possible for optimization flags to affect the BMI that is
produced. However, we allow BMIs built with one set of optimization / code
generation flags to be used in a compilation with the flags set
differently. And likewise for predefined macros, header search paths, and
similar things. We (mostly) don't allow mixing different languages and
language standards, though.
> | Likewise, there are nearly infinite numbers of PP symbols I can define
> | which have no effect on the BMI because they don't appear in the source
> | file.
> |
> | It doesn't seem implausible that compilers should be able to record
> | every PP symbol that was evaluated and its value, and ignore any symbols
> | outside that set for the purposes of determining if a BMI is
> "compatible".
>
> That is exactly what we are planning on doing for macros defined on the
> command line (configuration parameters) in MSVC.
>
> -- Gaby
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
sg15_at_[hidden]> wrote:
> | -----Original Message-----
> | From: Modules <modules-bounces_at_[hidden]> On Behalf Of Matthew
> | Woehlke
> | Sent: Tuesday, June 18, 2019 9:14 AM
> | To: Corentin <corentin.jabot_at_[hidden]>; modules_at_[hidden]
> | Cc: sg15_at_[hidden]; Olga Arkhipova <olgaark_at_[hidden]>
> | Subject: Re: [isocpp-modules] [SG15] Reuse of the built modules (BMI)
> paper
> |
> | On 18/06/2019 02.52, Corentin wrote:
> | > Is there anything as "slightly different compilation options" ? Given
> that
> | > almost everything can be observed from the source code, a compiler
> | should
> | > be conservative with what it considers "reusable".
> | > Let's not sacrifice correctness and reliability for the sake of
> compilation
> | > times (even if that appears to be often the case regardless of modules)
> |
> | Just because something is *observable* doesn't mean that it *is*
> | observed (or that it produces a change in the BMI even if it is). I
> | would guess that >90% of the time there are very few compile options
> | that actually affect the BMI.
> |
> | In fact, I would question if e.g. debugging information and optimization
> | levels affect the BMI. They affect the *object code*, sure enough, but
> | it seems like they *shouldn't* affect the BMI...
>
> You are right spot on for the case of MSVC. I wouldn't be surprised if
> that was the case of Clang too. I am less familiar with how GCC does
> things these days.
>
Yes, that's generally right for Clang too. We unfortunately expose some
details of optimization flags to the source code (eg, via the __OPTIMIZE__
macro), so it is possible for optimization flags to affect the BMI that is
produced. However, we allow BMIs built with one set of optimization / code
generation flags to be used in a compilation with the flags set
differently. And likewise for predefined macros, header search paths, and
similar things. We (mostly) don't allow mixing different languages and
language standards, though.
> | Likewise, there are nearly infinite numbers of PP symbols I can define
> | which have no effect on the BMI because they don't appear in the source
> | file.
> |
> | It doesn't seem implausible that compilers should be able to record
> | every PP symbol that was evaluated and its value, and ignore any symbols
> | outside that set for the purposes of determining if a BMI is
> "compatible".
>
> That is exactly what we are planning on doing for macros defined on the
> command line (configuration parameters) in MSVC.
>
> -- Gaby
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
Received on 2019-06-19 20:35:19