...in class members. The corresponding classes end up nested in the
class initializer of the surrounding class and we need to take this into
account when creating instances of ClassCodegen.
This fixes KT-40332 on the JVM IR backend.
JVM_IR has consistent stepping behavior for secondary constructors
and init blocks. This change fixes the expectations for tests that
expect the less consistent JVM backend behavior.
Temporary variable loads in when expressions had the offsets
of the variable declaration. That leads to hacks during codegen
for line number generation.
Instead of those hacks, give the variable loads the offsets of
the context in which they occur. That avoids the codegen hacks
and fixes stepping behavior for more when expressions.
NB some cases such as captured extension receiver for an extension
lambda are not supported yet; to be discussed, to what extent should we
actually follow JVM code shape here.
In JVM IR, both `valueParameters` and `isFromJavaOrBuiltins` take
noticeable time (1% of all compilation) because the logic for these in
IrBasedDescriptors is not trivial.
This takes BridgeLowering time percentage from 1.3% to 1.0% of all
compiler time on a sample project, perhaps due to better data locality.
In addition, it simplifies stack traces by effectively merging all
bridge generation call sites into one, helping in future performance
investigations.
First of all, put method signature caches of BridgeLowering into
JvmBackendContext. Since method hierarchies can span several files, and
a new instance of BridgeLowering is created to lower each file, keeping
them cached for the whole module makes BridgeLowering faster.
Also, do not attempt to compute special bridges if the method is
irrelevant, which can be deduced by its name. With this optimization,
the special method cache is no longer needed.
This brings BridgeLowering time from 3.8% down to 1.5% of all compiler
time on a sample project.
Default implementation of `IrStatement.transform` contained a cast to
`IrStatement`. Since almost all IR elements inherit from IrStatement,
this implementation was used in many subclasses. However, checkcast to
interface is slow and this place was indeed noticeable in the profiler
snapshot. Since not that many places really expected to get IrStatement
out of IrStatement.transform, introduce a new method
`transformStatement` that does this cast, and use it in all those
places. Meanwhile, most implementations will use the IrElement's
implementation of `transform` which merely invokes `accept` without
casts.
Also, inherit IrDeclarationBase from IrElementBase to be able to use a
cast to IrElementBase, which is faster than a cast to IrElement or
IrDeclaration.
IrElementTransformer.visitDeclaration/visitExpression are very prominent
hotspots, and it seems that HotSpot doesn't optimize the inlined Kotlin
bytecode there well enough. Reduce the bytecode in these and similar
methods by inlining calls to also/apply/transformChildrenVoid.
Merge IrMemberAccessExpressionBase into IrMemberAccessExpression, and
IrCallWithIndexedArgumentsBase into IrFunctionAccessExpression (extract
the latter into a separate file).
Implement no-op acceptChildren/transformChildren in the base class
IrExpressionBase instead. This doesn't change behavior because all other
implementations of acceptChildren/transformChildren are not affected.
Dmitriy Novozhilov