Specialize Any.{==, !=} when inlining #12157
Conversation
compiler/test/dotty/tools/backend/jvm/InlineBytecodeTests.scala
Outdated
Show resolved
Hide resolved
| case None => tree | ||
| } | ||
| case _ => | ||
| tree |
There was a problem hiding this comment.
What are the criteria for deciding what methods should be specialized? Is it possible to generalize the specialization?
There was a problem hiding this comment.
The criteria is that it is an == or != on Any
sel.symbol == defn.Any_== || sel.symbol == defn.Any_!=
and that the types of the compared values are the same value class
defn.ScalaValueClasses().find { cls =>
arg1.tpe.derivesFrom(cls) && arg2.tpe.derivesFrom(cls)
There was a problem hiding this comment.
We might generalize it for different classes. For example Short == Int.
The other potential generalization is on Numeric ops but that is much more complex.
There was a problem hiding this comment.
I am thinking why even specialize == and !=. This seems to related to the discussion about whether inlining should re-resolve selections. Such specialization helps very little in that perspective, I'm thinking whether it's worthwhile to complicate the compiler.
There was a problem hiding this comment.
No, in this case it is about the partial evaluation of the operation. If we have (2: Any) == (3: Any) we know that this will end calling 2 == 3 and return that result.
All the testing frameworks will benefit from this as the variants of assertEquals will generate this code. That is already a large enough use case.
Their specilized versions are known to have the same semantics as the generic `==` or `!=`. Improvement related to scala#11998
nicolasstucki
force-pushed
the
specialize-any-eq-on-inlining
branch
from
6908d97 to
48f0e89
Compare
|
Thanks @nicolasstucki ! |
Their specialized versions are known to have the same semantics as the generic
==or!=.Improvement related to #11998
Fiixes #12161