* double.compareTo(int) is fixed to handle integers which are not
precisely representable as doubles.
* int.compareTo(double) is fixed to properly handle doubles which
are clamped when converted to integers (with Dart 2.0 fixed-size
integers).
* Test for num.compareTo is updated for fixed-size integers; more corner
cases added.
Closes https://github.com/dart-lang/sdk/issues/31917
Change-Id: I8e98c3627f032082ab6a397713dece436585afd1
Reviewed-on: https://dart-review.googlesource.com/35004
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
The informal spec for strong mode top level inference
(https://github.com/dart-lang/sdk/pull/28218) says "If there are
multiple overridden/implemented methods, and any two of them have
non-equal types (declared or inferred) for a parameter position which
is being inferred for the overriding method, it is an error."
This CL fixes several SDK errors that arise from this rule. For
example, the classes _Closure, Function, and Object contained members
declared as follows:
class _Closure implements Function {
bool operator ==(other) ...
}
class Function {
bool operator ==(Object other) ...
}
class Object {
bool operator ==(other) ...
}
The type of Object's operator == was (dynamic) -> bool; the type of
Function's operator == was (Object) -> bool; therefore the type of
_Closure's operator == (which overrides both, since _Closure extends
Object and implements Function) cannot be inferred and must be
specified.
A similar situation exists for _Double and _IntegerImplementation
(both implement num, which declares operator == to have type (Object)
-> bool), and _Uri (which implements Uri, which declares operator ==
to have type (Object) -> bool).
This CL fixes the error by specifying the type explicitly in the
classes _Closure, _Double, _IntegerImplementation, and _Uri.
Change-Id: I91f7ceef8549399d438ba4be8c408493b3f338db
Reviewed-on: https://dart-review.googlesource.com/28100
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This reverts commit 30a942f728.
Plus:
1. Fixes integer type propagation in the optimizer by introducing a _int64 marker interface
2. Fixes calculation of whether an instructions can deoptimize: This has to be stable so that
once determined that an instructions can't deoptimize, it will stay that way and not flip back
later in the optimization
3. Address comments to improve CompileType::CopyNonNullable()
R=vegorov@google.com
Review-Url: https://codereview.chromium.org/2772143002 .
This reverts commit 890f694de5.
Previous commit was passing field_type_map_ down in a place where it was not passed down before.
This caused some handles to be used across zones, which caused crashes.
BUG=
Review URL: https://codereview.chromium.org/2453463006 .
Start by removing all get:runtimeType overrides in the patch files to have a single point computing the runtime type - Object.get:runtimeType. Handle string, double and integer types inside both intrinsic and runtime call to unify their handling and guarantee that code works even with intrinsifier disabled.
With overrides removed we can easily check that get:runtimeType is unique function name within the application that is being precompiled and use that to convert InstanceCall(get:runtimeType, ...) into StaticCall even nothing is known about the receiver.
This enables us to check if both left side and right side of comparison are StaticCall(Object.get:runtimeType, ...) when specializing InstanceCall(==, x, y). If they are we convert InstanceCall(==, StaticCall(get:runtimeType, a), StaticCall(get:runtimeType, b)) into StaticCall(Object._hasSameRuntimeType, a, b). A canonicalization rule will later delete unused get:runtimeType invocations.
Object._hasSameRuntimeType is implemented in C++ and intrinsified. It operates without creating new runtime types (except for Closures - where it does for simplicity). Cases of different class ids (i.e. a.[cid] != b.[cid]) and non-parameterized types are handled completely in the intrinsic. The rest is handled in the runtime code.
Microbenchmarking results:
Same parameterized classes: 15x improvement
Different parameterized classes: 300x improvement
Different/same non-parameterized classes: 2x improvement
BUG=
R=fschneider@google.com, regis@google.com
Review URL: https://codereview.chromium.org/2379733002 .
This pattern ensures the generation of 'and' instructions on the Smi x Smi path of a polymorphic & operation.
There are two 'and' operations on most simple _InternalLinkedHashMap and _CompactLinkedHashSet operations. One of the inputs, the hashCode, is occasionally a _Bigint. This change ensures that the usual case path has an 'and' instruction instead of a call to _IntegerImplementation.&
R=regis@google.com
Review URL: https://codereview.chromium.org/1913663002 .
Problems this addresses:
1. dart2js has hashCode functions like
get hashCode = this.x.hashCode + 17 * this.y.hashCode
When x and y are ints or bools VM optimizing compiler inlined the call
to Object.hashCode and generated MegamorphicLookups for
Object._identityHashCode.
2. HashMaps with _Smi keys had a double MegamorphicLookup: The hash
table reasonably calls MegamorphicLookup(get:hashCode) which returns
Object.hashCode; the compiled Object.hashCode is essentially
MegamorphicLookup(get:_identityHashCode), which returns
_Smi._identityHashCode which finally returns 'this'.
3. _interpolateSingle's call to o.toString() is megamorphic. We can
avoid it for the common case of String arguments, this is often
comming from StringBuffer.write() with a literal or interpolated
argument.
R=srdjan@google.com
Review URL: https://codereview.chromium.org/1820653002 .
Alexander Markov