On 5/1/24 12:11, Patrick Palka wrote:
On Wed, 1 May 2024, Jason Merrill wrote:
On 5/1/24 08:54, Patrick Palka wrote:
On Thu, 2 May 2024, Nathaniel Shead wrote:
On Wed, May 01, 2024 at 10:11:20AM -0400, Patrick Palka wrote:
On Wed, 1 May 2024, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
When calling instantiate_pending_templates at end of parsing, any new
functions that are instantiated from this point have their module
purview set based on the current value of module_kind.
This is unideal, however, as the modules code will then treat these
instantiations as reachable and cause large swathes of the GMF to be
emitted into the module CMI, despite no code in the actual module
purview referencing it.
This patch fixes this by also remembering the value of module_kind
when
the instantiation was deferred, and restoring it when doing this
deferred instantiation. That way newly instantiated declarations
appropriately get a DECL_MODULE_PURVIEW_P appropriate for where the
instantiation was required, meaning that GMF entities won't be counted
as reachable unless referenced by an actually reachable entity.
Note that purviewness and attachment etc. is generally only determined
by the base template: this is purely for determining whether a
specialisation was declared in the module purview and hence whether it
should be streamed out. See the comment on
'set_instantiating_module'.
PR c++/114630
PR c++/114795
gcc/cp/ChangeLog:
* cp-tree.h (struct tinst_level): Add field for tracking
module_kind.
* pt.cc (push_tinst_level_loc): Cache module_kind in
new_level.
(reopen_tinst_level): Restore module_kind from level.
(instantiate_pending_templates): Save and restore module_kind
so
it isn't affected by reopen_tinst_level.
LGTM. Another approach is to instantiate all so-far deferred
instantiations and vtables once we reach the start of the module
purview, but your approach is much cleaner.
Note that deferred instantiation can induce more deferred instantiation,
but your approach will do the right thing here (module_kind will be
inherited from the point of instantiation).
What if an instantiation is needed from both the GMF and the module
purview? Then IIUC it'll be instantiated as if from the GMF, which
seems right to me.
Hm..., so I believe it'll be marked according to whichever instantiates
it "first", so if e.g. deferred from GMF and then instantiated
non-deferred from purview it'll be marked purview (and the deferred
instantiation will be skipped as it's already instantiated). This could
mean it gets unnecessarily emitted if it only got instantiated because
it got used in e.g. a non-inline function body, I suppose; but that's
true in general actually, at the moment.
FWIW I think the most relevant situation where we need to instantiate
immediately and can't defer until EOF is during constexpr evaluation of
a variable initializer. (We also immediately instantiate variable
template specializations, and function template specializations with
deduced return type, but in these cases we'd always instantiate from the
first use, i.e. from the GMF in this scenario.)
So I guess a testcase for this situation could be something like:
module;
template<class T> constexpr int f(T t) { return t; }
template int f(int);
export module foo;
constexpr int w = f(0);
// f<int> ideally shouldn't be emitted in the CMI?
Does the explicit instantiation change that at all? Either way it seams like
f and f<int> aren't decl-reachable from w if we determine that after constant
evaluation.
Currently due to the bug in question we handle this as if the explicit
instantiation was performed from the module purview:
module;
template<class T> constexpr int f(T t) { return t; }
export module foo;
template int f(int);
constexpr int w = f(0);
I think we do want to emit f<int> in that case?
Agreed, because f is decl-reachable from the explicit instantiation in
the module purview.
I was suggesting that there's no effective difference between explicit
instantiation in the GMF and implicit instantiation.
Jason
