1. 12 Apr, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Properly represent the float64 hole. · 8c0c5e81
      bmeurer authored
      The hole NaN should also have proper Type::Hole, and not silently hide
      in the Type::Number. This way we can remove all the special casing for
      the hole NaN, and we also finally get the CheckNumber right.
      
      This also allows us to remove some ducktape from the Deoptimizer, as for
      escape analyzed FixedDoubleArrays we always pass the hole value now to
      represent the actual holes.
      
      Also-By: jarin@chromium.org
      BUG=chromium:684208,chromium:709753,v8:5267
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2814013003
      Cr-Commit-Position: refs/heads/master@{#44603}
      8c0c5e81
  2. 21 Mar, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Slightly improve truncations for CheckBounds. · 17d932c0
      bmeurer authored
      For CheckBounds(index,length) we know that the length must be in
      Unsigned31 range. Thus there's no observable difference for index
      values in the range [-2^31,-1] and the range [2^31,2^32-1], both
      are considered out-of-bounds; also it's safe to truncate -0 to 0
      wrt. CheckBounds. Thus we can safely pass Word32 truncation if the
      index is in Integral32 \/ MinusZero. Usually this generates the same
      code, but some index computations can benefit from the Word32 truncation
      and avoid going to double because the result would be outside the valid
      Signed32 or Unsigned32 ranges.
      
      R=jarin@chromium.org
      BUG=v8:5267
      
      Review-Url: https://codereview.chromium.org/2760213003
      Cr-Commit-Position: refs/heads/master@{#43969}
      17d932c0
  3. 18 Feb, 2017 1 commit
    • vabr's avatar
      Fix typeof optimization for undetectable · 6302753e
      vabr authored
      Currently, typeof o, where o is an undetectable
      callable object (such as document.all), returns 'function' if
      optimised. It should, however, return 'undefined'.
      
      This CL excludes undetectable objects from the optimization
      resulting in type 'function' and renames the related code to
      reflect that.
      
      BUG=v8:5972
      R=bmeurer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2697063002
      Cr-Commit-Position: refs/heads/master@{#43298}
      6302753e
  4. 14 Feb, 2017 1 commit
  5. 13 Feb, 2017 4 commits
  6. 09 Feb, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Utilize the fact that empty string is canonicalized. · cd9724d4
      bmeurer authored
      Since the empty string is canonical HeapObject now, we can use
      this fact to optimize
      
        - strict equality comparisons with the empty string to a
          simple ReferenceEqual operation, and
        - optimize ToBoolean to avoid instance type checks completely.
      
      Drive-by-fix: Allow InternalizedString for Type::HeapConstant
      in the type system. This is safe, since InternalizedStrings
      can be compared to other heap constants by reference (except
      for non-InternalizedStrings, which are excluded from the
      HeapConstant type).
      
      BUG=v8:5267
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2681273002
      Cr-Commit-Position: refs/heads/master@{#43050}
      cd9724d4
  7. 20 Jan, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Properly implement %_ClassOf intrinsic. · 3e407093
      bmeurer authored
      The %_ClassOf intrinsic roughly corresponds to the deprecated ES5
      [[Class]] internal property, and should not be used anymore ideally.
      However since we still have quite a couple of uses of this intrinsic
      in the self hosted JavaScript builtins, we would tank some builtins
      like Map, Set, WeakMap, WeakSet, etc. quite significantly unless we
      also support this intrinsic until the builtins are all migrated to
      C++/CSA builtins.
      
      R=yangguo@chromium.org
      BUG=v8:5267
      
      Review-Url: https://codereview.chromium.org/2647833004
      Cr-Commit-Position: refs/heads/master@{#42530}
      3e407093
  8. 19 Jan, 2017 1 commit
  9. 09 Jan, 2017 1 commit
  10. 22 Dec, 2016 1 commit
  11. 29 Nov, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Add appropriate types to express Callable. · 777e142c
      bmeurer authored
      This introduces three new types OtherCallable, CallableProxy (and OtherProxy),
      and BoundFunction to make it possible to express Callable in the Type system.
      It also forces all undetectable receivers to be Callable, which matches the
      use case for undetectable, namely document.all (guarded by proper checks and
      tests).
      
      It also uses these new types to properly optimize instanceof (indirectly via
      OrdinaryHasInstance) based on the type of the constructor and the object. So
      we are able to constant-fold certain instanceof expressions based on types
      and completely avoid the builtin call.
      
      R=jarin@chromium.org
      BUG=v8:5267
      
      Review-Url: https://codereview.chromium.org/2535753004
      Cr-Commit-Position: refs/heads/master@{#41345}
      777e142c
  12. 24 Nov, 2016 1 commit
  13. 14 Nov, 2016 1 commit
  14. 11 Nov, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Introduce an ExternalPointer type. · 7d24f1ae
      bmeurer authored
      This adds a new ExternalPointer type, which is an Internal type that is
      used for ExternalReferences and other pointer values, like the pointers
      into the asm.js heap. It also adds a PointerConstant operator, which we
      use to represents these raw constants (we can probably remove that
      particular operator again once WebAssembly ships with the validator).
      
      R=mvstanton@chromium.org
      BUG=v8:5267,v8:5270
      
      Review-Url: https://codereview.chromium.org/2494753003
      Cr-Commit-Position: refs/heads/master@{#40923}
      7d24f1ae
  15. 17 Oct, 2016 1 commit
  16. 08 Oct, 2016 1 commit
  17. 06 Oct, 2016 1 commit
    • mvstanton's avatar
      [Turbofan] Introduce OtherNumberConstant. · 978fe70b
      mvstanton authored
      With this CL, we devolve all Constants introduced as they are with an object handle into
      
      * Range - for integers
      * Nan
      * MinusZero
      * OtherNumberConstant - for doubles
      * HeapConstant
      
      We reduce the amount we have to inspect an object handle during optimization. Also, simplifications result. For example, you never have to check if a Range contains a HeapConstant.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2381523002
      Cr-Commit-Position: refs/heads/master@{#40041}
      978fe70b
  18. 28 Sep, 2016 1 commit
  19. 27 Sep, 2016 1 commit
  20. 26 Sep, 2016 2 commits
  21. 23 Sep, 2016 1 commit
  22. 22 Sep, 2016 1 commit
  23. 12 Sep, 2016 1 commit
  24. 05 Sep, 2016 4 commits
  25. 02 Sep, 2016 1 commit
    • mvstanton's avatar
      Forking the type system between Crankshaft & Turbofan. · 17e9e2f4
      mvstanton authored
      Our Type class has a semantic and representational dimension.
      Much code in src/ast, Crankshaft and Turbofan is based on it.
      Going forward in Turbofan we'd like to remove representational information
      entirely. To that end, new type AstType has been created to preserve
      existing behavior for the benefit of Crankshaft and the AST.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2302283002
      Cr-Commit-Position: refs/heads/master@{#39135}
      17e9e2f4
  26. 31 Aug, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Remove remaining uses of Class type from the compiler. · 2b938990
      bmeurer authored
      We (mis)used Type::Class to track stable field maps in the past. But
      that always more or less unsupport and wrong for various reasons, mostly
      because the class types do not really present static information and
      thus it is possible to violate fundamental assumptions of the type
      system (i.e. intersecting class types and other types produces
      "interesting" results).
      
      Now it is possible to finally nuke the class types completely and thus
      simplify (and ideally correctify) the type system further.
      
      Note to performance sheriff: We do expect to see some performance
      regressions from this change. This is because we do not yet have a sane
      replacement mechanism to track known field maps and utilize them during
      LoadElimination. This will be accomplished in a follow up CL.
      
      BUG=v8:5270,v8:5267
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2293343002
      Cr-Commit-Position: refs/heads/master@{#39031}
      2b938990
  27. 17 Aug, 2016 1 commit
    • mstarzinger's avatar
      [turbofan] Remove representation axis for float64 fields. · 5c6719fc
      mstarzinger authored
      This removes the representation axis from the type of {Load/StoreField}
      operators representing a property load/store. The representation would
      be narrowed to {None} which causes problems for all places where we use
      the type to reason about the value representation. Instead we should
      fully switch to {MachineRepresentation}. This is just a stop-gap fix.
      
      R=jarin@chromium.org
      BUG=chromium:636716
      
      Review-Url: https://codereview.chromium.org/2255533003
      Cr-Commit-Position: refs/heads/master@{#38678}
      5c6719fc
  28. 10 Aug, 2016 1 commit
  29. 03 Aug, 2016 2 commits
    • bmeurer's avatar
      [turbofan] Unify number operation typing rules. · 66e96fc9
      bmeurer authored
      Move all the typing rules for unary and binary number operations to the
      OperationTyper and use them for both the regular Typer as well as the
      retyper that runs as part of SimplifiedLowering.
      
      R=epertoso@chromium.org
      
      Review-Url: https://codereview.chromium.org/2202883005
      Cr-Commit-Position: refs/heads/master@{#38283}
      66e96fc9
    • bmeurer's avatar
      [turbofan] Improve typing rule for modulus. · 17a7f583
      bmeurer authored
      Infer a more precise type even in case where NaN and/or -0 is a possible
      outcome of the operation, and use this more precise type to improve code
      generation for the modulus itself by trying harder to stick to Word32
      operations instead of going to Float64, and also optimize the pattern
      where we compare the output of x % y to some non-zero integer constant
      K, in which case we can truncate the output of x % y to Word32 if the
      type of x % y is Signed32/Unsigned32 \/ NaN \/ MinusZero, as NaN and
      MinusZero will both be truncated to zero, which cannot match the non
      zero constant K.
      
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2202413002
      Cr-Commit-Position: refs/heads/master@{#38267}
      17a7f583
  30. 15 Jun, 2016 2 commits
  31. 01 Jun, 2016 1 commit