Allow kotlin.jvm.internal.Intrinsics#areEqual for boxed values.
Rewrite to primitive equality.
NB we can't do that for Float and Double, because java.lang.Float#equals
and java.lang.Double#equals behave differently from primitive equality comparisons.
CHECKCAST is redundant if the corresponding static type exactly matches the target type.
CHECKCAST instructions to-be-reified should not be eliminated.
KT-14811 Unnecessary checkcast generated in parameterized functions
KT-14963 unnecessary checkcast java/lang/Object
KT-16194 Code with unnecessary safe call contains redundant boxing/unboxing for primitive values
KT-12839 Two null checks are generated when manually null checking platform type
Recognize some additional cases of trivial null checks and trivial instance-of checks.
A variable is "checked for null", if it is:
- a function parameter checked with 'INVOKESTATIC kotlin/jvm/internal/Intrinsics.checkParameterIsNotNull'
- checked for nullability with 'IFNULL/IFNONNULL'
- checked for nullability with 'INSTANCEOF'
(if objectref is instance-of T, then objectref is non-null)
Before analyzing nullability, introduce synthetic assumptions for execution branches
where a variable is guaranteed to be null or not null. For example, the following bytecode:
ALOAD 1 // Ljava/lang/String;
IFNULL L
<non-null branch>
L:
<null branch>
is transformed to
ALOAD 1
IFNULL L1
NEW java/lang/String
ASTORE 1 // tells analyzer that variable 1 is non-null
<non-null branch>
L:
<null branch>
L1:
ACONST_NULL
ASTORE 1 // tells analyzer that variable 1 is null
GOTO L
After the analysis is performed on a preprocessed method,
remember the results for "interesting" instructions
and revert the preprocessing transformations.
After that, perform bytecode transformations as usual.
Do not transform INSTANCEOF to-be-reified, because reification at call site
can introduce null checks. E.g.,
inline fun <reified T> isNullable() = null is T
...
assert(isNullable<String?>())
Finnaly markers are used only for non-local return processing and are removed after inlining to non-inline functions, same deletion should be performed on inlining to anonymous objects
#KT-16532 Fixed
Previous version of the boxing/unboxing analysis treated merging boxed and non-boxed values as a hazard.
If such merged values are not used (e.g., early return + local variables reused in inlined calls),
corresponding boxing/unboxing operations still can be optimized out.
All information related to boxed value usage by instructions is moved to 'BoxedValueDescriptor'.
Introduce "tainted" (and "clean") boxed values, with the following rules:
merge(B, B) = B, if unboxed types are compatible,
T, otherwise
merge(B, X) = T
merge(T, X) = T
where
X is a non-boxed value,
B is a "clean" boxed value,
T is a "tainted" boxed value.
Postpone decision about value merge hazards until a "tainted" value is used.
Remove redundant NOPs during bytecode optimization.
NOP instruction is required iff one of the following is true:
(a) it is a first bytecode instruction in a try-catch block (JVM BE assumption);
(b) it is a sole bytecode instruction in a source code line (breakpoints on that line will not work).
All other NOP instructions can be removed.
Note that it doesn't really affect the performance for mature JVM implementations.
However, the perceived quality of the generated code is somewhat improved :).
Related: KT-15609
- `invoke` method must always start a suspend functions
- For creation of coroutine that has not been started yet, there are
two special internal interfaces `SuspendFunction0`/`SuspendFunction1`
It fixes VerifyError with coroutines on Dalvik happening because of
variables spilling before/after suspension point
BasicInterpreter from ASM does not distinct 'int' types from other
int-like types like 'byte' or 'boolean', neither do HotSpot and JVM spec.
But it seems like Dalvik does not follow it, and spilling
boolean value into an 'int' field fails with VerifyError on Android 4,
so it's necessary to distinct int types for variables spilling
#KT-13289 Fixed
Do not treat var as alive just because current instruction belongs to an item range
in local variables table, but the item has different sort of type
As liveness analysis is mostly used in coroutines spilling,
not applying this change may lead that to problems on Android (see tests)
