dart2js cps: Better 'is int' checks.

pkg/compiler/lib/src/cps_ir/builtin_operator.dart

 // Copyright (c) 2015, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 library builtin_operator;
 // This is shared by the CPS and Tree IRs.
 // Both cps_ir_nodes and tree_ir_nodes import and re-export this file.
 
 /// An operator supported natively in the CPS and Tree IRs using the
 /// `ApplyBuiltinOperator` instructions.
 ///
 /// These operators are pure in the sense that they cannot throw, diverge,
 /// have observable side-effects, return new objects, nor depend on any
 /// mutable state.
 ///
 /// Most operators place restrictions on the values that may be given as
 /// argument; their behaviour is unspecified if those requirements are violated.
 ///
 /// In all cases, the word "null" refers to the Dart null object, corresponding
 /// to both JS null and JS undefined.
+///
+/// Some operators, notably [IsFloor] and [IsNumberAndFloor], take "repeated"

[karlklose, 2015/06/18 07:36:56]

We could avoid this problem by adding 'typeof' and 'Math.isFloor' as builtin
operators instead.  WDYT?

[asgerf, 2015/06/18 09:08:49]

(Summary from offline discussion with Karl)

I agree that it's somewhat unusual, but I wouldn't go as far as calling it a
problem, because there really is no harm in it. It has the positive benefit of
bringing awareness to an issue that is otherwise easily overlooked.

Try to see codegen_helpers.dart:410 to see the corresponding logic in SSA. The
"complexity" was there all along, we are just tackling it head on instead of
leaving it as a subtlety for assignment propagation to think about.

But is true, with more fine-grained operators, it would go away entirely. But
there are some drawbacks to fine-grained operators:
1. They require more IR nodes at runtime.
2. Building complex expressions is more complicated than just adding one
operator.
3. Analyzing the resulting IR is harder. The IR for IsNumberAndFloor would
require two LetConts and a Branch, and then it's much harder to see that it just
checks if a value is an integer.

+/// arguments to reflect the number of times the given value is referenced
+/// by the generated code. The tree IR needs to know the number of references
+/// to safely propagate assignments.
 enum BuiltinOperator {
   /// The numeric binary operators must take two numbers as argument.
   /// The bitwise operators coerce the result to an unsigned integer, but
   /// otherwise these all behave like the corresponding JS operator.
   NumAdd,
   NumSubtract,
   NumMultiply,
   NumAnd,
   NumOr,
   NumXor,
@@ skipping 18 matching lines @@
   /// One of the following must hold:
   /// - At least one argument is null.
   /// - Arguments are both strings, or both booleans, or both numbers.
   LooseEq,
 
   /// Negated version of [LooseEq]. Introduced by [LogicalRewriter] in Tree IR.
   LooseNeq,
 
   /// Returns true if the argument is false, +0. -0, NaN, the empty string,
   /// or null.
-  IsFalsy
+  IsFalsy,
+
+  /// Returns true if the argument is a number.
+  ///
+  /// Compiles to `typeof x === 'number'`
+  IsNumber,
+
+  /// Returns true if the argument is not a number.
+  ///
+  /// Compiles to `typeof x !== 'number'`.
+  IsNotNumber,
+
+  /// Returns true if the argument is an integer, false if it is a double or
+  /// null, and unspecified if it is anything else.
+  ///
+  /// The argument must be repeated 2 times.
+  ///
+  /// Compiles to `Math.floor(x) === x`
+  IsFloor,
+
+  /// Returns true if the argument is an integer.
+  ///
+  /// The argument must be repeated 3 times.
+  ///
+  /// Compiles to `typeof x === 'number' && Math.floor(x) === x`
+  IsNumberAndFloor,
 }