[tlively]

In GlobalStructInference::analyzeClosedWorld, unoptimizable types and typeGlobals are propagated from subtypes up to all declared supertypes because a struct.get or ref.get_desc on a non-exact reference to $super might access an instance of any subtype $sub. However, FunctionOptimizer::optimize also looked up typeGlobals[heapType] when the reference operand had an exact type (ref null? (exact $super)), which can never hold an instance of a strict subtype $sub at runtime. When optimizing (ref.get_desc $super ref) on an exact reference of type (ref (exact $super)), including globals that initialize a strict subtype $sub caused getReadValue to produce descriptors of type (ref (exact $sub.desc)), which is not a subtype of (ref (exact $super.desc)), widening the select result type to non-exact (ref $super.desc) and failing validation.

Save exactTypeGlobals after erasing directly unoptimizable types and before propagating unoptimizability and globals from subtypes to supertypes, and consult exactTypeGlobals in FunctionOptimizer::optimize when ref->type.isExact().

[gemini-code-assist]

Code Review

This pull request introduces exactTypeGlobals to the GlobalStructInference pass to optimize reads of exact references, which cannot refer to strict subtypes. This allows exact references to be optimized even when their supertypes or subtypes are unoptimizable. The feedback suggests sorting the vectors in exactTypeGlobals lexicographically to ensure determinism and consistency in the optimization output.

[gemini-code-assist]

To ensure determinism and consistency, the vectors in exactTypeGlobals should be sorted lexicographically, just like typeGlobals is sorted at the end of analyzeClosedWorld. Since exactTypeGlobals is not modified after this copy, sorting it here guarantees that the optimization output remains independent of the order of globals in the module.

Suggested change

	exactTypeGlobals = typeGlobals;
	exactTypeGlobals = typeGlobals;
	for (auto& [type, globals] : exactTypeGlobals) {
	std::sort(globals.begin(), globals.end());
	}

[kripken]

As above, this global has type super but instantiates sub. Do we have a test where a global has type sub?

[tlively]

Yes, global $A in the first module in this file.

[kripken]

lgtm otherwise