Another instance of use that could be eliminated is _: XYZ.type in a case clause.

Will update head comment.

What happens if you mark blahName as @inline?

@sjrd I guess we could teach the optimizer to check for existence of instances when doing isInstanceOf checks, which should fold the if branch. The question is how much impact this will have on invalidation.

Well here the thing the optimizer sees is if (XYZ == b). Collapsing that to false is hard.

What happens if you mark blahName as @inline?

Just gave it a try with @inline; it doesn't eliminate XYZ.

Well here the thing the optimizer sees is if (XYZ == b). Collapsing that to false is hard.

I don't know if this is a naive view but I imagine this optimisation could be implemented by something like:

• change usage analysis of case objects so that references (usages) are recorded in two distinct buckets: one for value inspection usage like case clauses, equality or reference comparison, instanceOf checking; and a bucket for everything else.
• DCE₁: remove objects without any references in usage-bucket-2.
• DCE₂: for all references in all removed objects' usage-bucket-1s, remove case clauses, collapse equality tests to constant false.
• Today's DCE runs and removes dead branches which now includes those introduced above.

Would that work? Is the reason you foresee this being hard due to logic (in that above is too naive) or in implementation?

Not really. What we want to get rid of is Obj == x (Scala's equality) for pattern matching. But == is not always reference equality. For example Nil == Vector.empty.

After a round of optimization, == simplifies to === (aka eq) when that's the actual implementation. But after the optimizer we only have one round of dce left, which is not enough to implement the rest of your "plan" (steps 2 and following). In particular what you call "DCE 2" actually needs a round of optimization, not dce.

Note to self: It seems like

• Ignoring _ === LoadModule(_) trees in reachability analysis and
• Folding the above to false if the module isn't instantiated

Will give us the optimization we'd want. But the second step comes too late (Emitter would be our earliest phase). We can optimize the expression, but we cannot eliminate code that is unused because of it, providing limited value.

(Yes, this is what sjrd has been saying all along)

I've had another (unsuccessful) pass at this. Sharing a negative result.

IIUC, as an approximation, the IR trees we are interested in are:

x.equals;Ljava.lang.Object;Z(y)

where x is a value of

• module class type,
• without an override of equals

My thought was to special case this in the Analyzer (in callMethod) to
extract the fact that we are checking module class identity.

This seems to be possible; however, it does not solve the problem:
we cannot trace back what x is in the analyzer phase, so we cannot
eliminate / flag the LoadModule call (which we assigned to x) as "readonly".

It seems like the only other option (short of adding another optimizer-like phase)
would be to investigate compiler support (compile to a linker friendlier tree).
But IIUC that would not work in terms of separate compilation guarantees we need to offer (a module class needs to be able to override equals without re-compilation of usage sites).