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.