On Fri, Nov 13, 2020 at 3:04 PM Nathan Sidwell <nat...@acm.org> wrote:
>
> Here are the pieces of patch 22 that add new flag bits to tree nodes and
> lang_decl structs, along with a new global indicating what fragment of a
> module we may be processing.
>
> be aware that header-units, although part of the Global Module, are
> treated as-if they are named modules but with some interesting 'may have
> duplicate' rules. In particular all their entities are exported, and
> marked as having a purview
>
> There was a free LANG_DECL flag, which I use for DECL_MODULE_EXPORT_P,
> such a decl is being exported from somewhere.
>
> I needed to mark typeinfo types, so DECL_TINFO_P is extended to TYPE_DECLs.
>
> OVL_EXPORT_P is added to indicate that a particular member is an export.
> This is duplicating DECL_MODULE_EXPORT_P, but it is convenient to have
> it in the overload.
>
> DECL_MODULE_PURVIEW_P -- the decl is in the purview of a module
>
> DECL_MODULE_IMPORT_P -- we got this decl from an import
>
> DECL_MODULE_ENTITY_P -- this decl is in the imported entity array &
> hash. It may be true even if DECL_MODULE_IMPORT_P is false, because the
> current TU might be defining it.
>
> DECL_MODULE_PENDING_SPECIALIZATIONs, this template decl has
> specializations that we have not loaded (they must be loaded before we
> can instantiate the template) such specializations can be in arbitray
> modules, not necessarily the one defining the template
>
> DECL_MODULE_PENDING_MEMBERS, likewise, we can define members in other
> modules (partitions or header units), or instantiate implicit members
> anywhere. These need to be loaded before we can look inside this class.
>
> DECL_ATTACHED_DECLS_P, this namespace-scope decl has a set of attached
> decls for ODR purposes. The case we handle comes from ranges:
>
> template<something> constexpr T var = [] () { return something; }
>
> That lambda is attached to 'var', it's not a different lambda in each TU.
>
> Nearly all those new flags are added to lang_decl_base. Originally I
> had the module index there, which is why I drastically shrank
> 'selector'. I keep the shrinkage because I don't really think it's a
> bottleneck.
>
> class module_state is defined inside module.cc, but we need to expose
> its incomplete tag. 'modules_p' is true if we're supporting modules.
> IIRC I had one bug during development where a modules-disabled
> compilation crashed. So I'm reasonably certain that, when disabled, the
> compiler is still as stable as ever.
>
> module_kind is a set of bits indicating what kind of module we're
> processing. non-module code will have it zero. In module purview
> MK_MODULE will be set. In the GMF of a named module MK_GLOBAL will be
> set (and MK_MODULE clear). In a header unit, both are set.
>
> MK_EXPORTING is set if we're inside an 'export' either a {...} region,
> or a single decl. MK_INTERFACE is true if we're in the interface of a
> named module (as opposed to implementation), and MK_PARTITION is true if
> we're in a partition of a named module (interface or implementation).
>
> There are a bunch of inline predicate functions to decode the various
> combinations that are useful.
struct GTY(()) lang_decl_base {
- /* Larger than necessary for faster access. */
- ENUM_BITFIELD(lang_decl_selector) selector : 16;
+ ENUM_BITFIELD(lang_decl_selector) selector : 3;
...
+ unsigned attached_decls_p : 1;
+
+ /* 10 spare bits. */
so for "faster access' you could still make selector 8 bits, reducing
spare bits to 5.
Can you add comments (like on some other bits var / fn / type)
what kind of decls the new bits are used on? Maybe some
bits can be overloaded if spare bits are needed.
Thanks,
Richard.
> nathan
>
> --
> Nathan Sidwell
