Use exactness to optimize GUFA cone depth

[tlively]

Exact references are known to point to exactly their heap type and not
one of its subtypes. GUFA already analyzed exactness via the more
general "cone" types that include an allowed subtyping depth. Exact
types are equivalent to cone types of depth zero. Let GUFA take
advantage of exactness information by normalizing cone depths to 0
whenever the cone type is exact.

[kripken]

Hmm, why doesn't this work without exact types? GUFA's depth zero cone should have had enough information already.

[tlively]

Note that the sources are imports, not allocations, so without the new changes, GUFA doesn't know that it can use 0-depth cones for those imports.

[kripken]

Oh right, thanks!

[kripken]

I think this might be a better place:

diff --git a/src/ir/possible-contents.h b/src/ir/possible-contents.h
index 538b23d4d..ab5b53436 100644
--- a/src/ir/possible-contents.h
+++ b/src/ir/possible-contents.h
@@ -164,8 +164,8 @@ public:
     assert(type != Type::none);
 
     if (type.isRef()) {
-      // For a reference, subtyping matters.
-      return fullConeType(type);
+      // For a reference, subtyping matters, unless it is exact.
+      return type.isExact() ? exactType(type) : fullConeType(type);
     }
 
     if (type == Type::unreachable) {

That applies exactness on creation. I think it should be enough here?

[tlively]

It looks like fullConeType is also used directly in several places. WDYT about having this check in fullConeType so it's harder to inadvertently skip?

[kripken]

Ah, good point. Yeah, that seems safest.

[kripken]

Does this need to change? It seems odd to consider a code of depth 0 as "full".

[tlively]

Yes, otherwise a bunch of assertions expecting full cone types started failing. I think it makes sense to make cone creation and inspection consistent in treating depth-0 cones for exact types as "full," so I think this is a better solution than going and changing those assertions.

[kripken]

I'd like to understand this better - which assertions were those?

[tlively]

The assertion at the top of PossibleContents::intersect.

// This does not yet handle all possible content.
assert(other.isFullConeType() || other.isLiteral() || other.isNone());

Looking deeper into PossibleContents::intersect and the other methods it calls, it's a little difficult to tell whether they do the right thing with exact types. I propose 1) moving forward with this change as-is to see if further fuzzing with exact types turns up any issues and 2) adding more possible-contents gtests covering exact types in a follow-up.

[kripken]

Hmm, that assert looks suspicious to me... I'd rather investigate that first, but I don't feel strongly.

If you want to land this quickly to unblock other stuff, how about doing the reverse: modify the assert to allow either a full cone or an exact type, so we don't need to modify hasFullCone? I can also take a look at the PossibleContents code if you want.

[tlively]

No rush to land this. I can reorder things to avoid getting blocked. I do think it would be weird if a value created by fullConeType did not satisfy hasFullCone or isFullCone, though.

[kripken]

Yeah, we should rename fullConeType probably. Really what it does now is create a cone based on the type. Just coneType might be enough.

[tlively]

Closing in favor of #7582