last-exclusive progressions (i.e., "until" progressions and loop over
array indices).
This change makes it possible to correctly implement the handling of
"step" progressions. Computing the last element of a stepped progression
requires that the last is inclusive.
Also invert the while loop (into if + do-while) that is used when
lowering for-loops over progressions that cannot overflow. This keeps
the performance characteristics closer to the ForLoopsLowering in
kotlin-native, since the goal is to converge to this shared version.
Also used IrType instead of KotlinType, where possible.
https://github.com/JetBrains/kotlin/pull/2390https://github.com/JetBrains/kotlin/pull/2305
Unfortunately this cannot currently be done for the extension overload which accepts a radix due to behavior difference with regard to invalid radix values.
Remove "JVM_TARGET: 1.6" directive from box tests and remove tests with
JVM target 1.8. By default, box tests are run with JVM target 1.6, and
there's an additional configuration `codegenTarget8Jvm8Test` that runs
all box tests with JVM target 1.8.
Also, remove box tests with JVM target 1.6. They aren't needed because
even if we manage to generate incorrect bytecode with target 1.6, the
corresponding box tests will catch that
We get the info for the underlying progression and invert it. For
progressions whose last bound was open (e.g., `until` loop), the
reversed version will have an open first bound and so the induction
variable must be incremented first.
Also unified the way of extracting HeaderInfo out of changed calls
(e.g., `indices.reversed()`), and fixed declaration parents in
ForLoopsLowering.
do-while with enclosing "not empty" check).
Also do not add additional "not empty" condition for `until` loops when
the given bound is a constant != MIN_VALUE.
Effectively, the following when structure:
when (s) {
s1, s2 -> e1,
s3 -> e2,
s4 -> e3,
...
else -> e
}
is implemented as:
when (s.hashCode()) {
h1 -> {
if (s == s1)
e1
else if (s == s2)
e1
else if (s == s3)
e2
else
e
}
h2 -> if (s == s3) e2 else e,
...
else -> e
}
where s1.hashCode() == s2.hashCode() == s3.hashCode() == h1,
s4.hashCode() == h2.
A tableswitch or lookupswitch is used for the hash code lookup.
Change-Id: I087bf623dbb4a41d3cc64399a1b42342a50757a6
Specifically, defer the removal of hand-written "if (true|false)" from
JvmBuiltinOptimizationLowering into codegen so that appropriate debug
info (and a NOP) can be inserted.
Change-Id: Ia11af05ad8b4251946bd3e685fb7c3319f0f433f
A lookupswitch or tableswitch can be used if all conditions are equality
checks to constants. To be more specific, it can be done if:
1. All conditions are CALL 'EQEQ(Any?, Any?)': Boolean
2. All types of variables involved in comparison are in the same group
of Char/Byte/Short/Int, String or enum.
3. All arg0 refer to the same value.
4. All arg1 are IrConst<*>.
Change-Id: Ifd7cb618395f6c5cc64601018b446f0bb7f5891c
The generated code is more inline with java, and we avoid the error of
accessing package-private field outside of the package.
However, this changes semantics a bit. Now, a user should set assertion
status of inline-site's package, instead of inline function's one.
#KT-28317: Fixed
Initializers are "set field" expressions and are considered redundant
when they are:
1. In the primary constructor; and
2. Set the field to `0`, `false`, or `null`; and
3. Have a `null` origin. I.e., not in an initializer block or
constructor body, and therefore the field could not have been set by a
prior expression.
Simplify ifs when branches have condition true/false.
Simplify blocks containing only a variable declaration
and a variable get of the same variable. Simplify to
just the condition.
Do not introduce temporary variables for constants for
null checks. Constants have no side-effects and can be
reloaded freely instead of going through a local.
This simplifies code such as "42.toLong()!!" so that the
resulting code has no branches and uses no locals. The
simplifications happen as follows:
```
block
temp = 42.toLong()
when
(temp == null) throw NPE
(true) load temp
---> null test simplification
block
temp = 42.toLong()
when
(false) throw NPE
(true) load temp
---> when simplification
block
temp = 42.toLong()
load temp
---> block simplification
42.toLong()
```
Introduce lowering to remove null checks for primitive type
expressions and replace them with true/false. Side-effects
are preserved.
Generate ifnull/ifnonnull instructions for null checks instead
of materializing a null literal for an equality check.
Most of these tests used this directive as a way to opt in to a new
language feature, and most of those features are already stable for a
long time, so no opt-in is needed. Some other tests used the directive
to opt out from a language feature, replace those by the `LANGUAGE`
directive. One test used the directive to test behavior that actually
depended on the API version; use `API_VERSION` directive there instead.
Previously, for a property named `x` in the companion object of a class
named `Foo`, we generated:
- `Foo.access$getX$cp`, consisting of `GETFIELD Foo.x` and lateinit
assertion
- `Foo.Companion.getX`, consisting of `INVOKEVIRTUAL Foo.access$getX$cp`
Now, we generate:
- `Foo.access$getX$cp`, consisting of `GETFIELD Foo.x`
- `Foo.Companion.getX`, consisting of `INVOKEVIRTUAL Foo.access$getX$cp`
and lateinit assertion
The reason is that this way we can avoid generating another accessor and
reuse `Foo.access$getX$cp` in case `isInitialized` is called on a
lateinit property from companion.
For private properties, getX is not generated, but instead the assertion
is generated on each access to the field (which can be improved, see
KT-28331). The same happens for access to non-private properties from
inside the same context where they're declared.
#KT-21862 In Progress
Sometimes, state-machine, generated in inline functions with
crossinline parameter, is transformed, since all usages should be
renamed.
However, this is wrong: in this case, we will have state-machine
inside state-machine.
This fix addresses the issue.
#KT-25893 Fixed
Steven Schäfer