1. 28 Sep, 2016 1 commit
  2. 27 Sep, 2016 1 commit
  3. 26 Sep, 2016 2 commits
  4. 23 Sep, 2016 1 commit
  5. 22 Sep, 2016 1 commit
  6. 12 Sep, 2016 1 commit
  7. 05 Sep, 2016 4 commits
  8. 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
  9. 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
  10. 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
  11. 10 Aug, 2016 1 commit
  12. 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
  13. 15 Jun, 2016 2 commits
  14. 01 Jun, 2016 1 commit
  15. 27 Feb, 2016 1 commit
  16. 26 Feb, 2016 1 commit
  17. 24 Feb, 2016 1 commit
    • bmeurer's avatar
      [compiler] Drop the CompareNilIC. · 666aec03
      bmeurer authored
      Since both null and undefined are also marked as undetectable now, we
      can just test that bit instead of having the CompareNilIC try to collect
      feedback to speed up the general case (without the undetectable bit
      being used).
      
      Drive-by-fix: Update the type system to match the new handling of
      undetectable in the runtime.
      
      R=danno@chromium.org
      
      Review URL: https://codereview.chromium.org/1722193002
      
      Cr-Commit-Position: refs/heads/master@{#34237}
      666aec03
  18. 17 Feb, 2016 1 commit
  19. 16 Feb, 2016 1 commit
  20. 02 Feb, 2016 1 commit
    • jarin's avatar
      Remove the template magic from types.(h|cc), remove types-inl.h. · ef35f11c
      jarin authored
      This CL removes the Config templatization from the types. It is not
      necessary anymore, after the HeapTypes have been removed.
      
      The CL also changes the type hierarchy - the specific type kinds are
      not inner classes of the Type class and they do not inherit from Type.
      This is partly because it seems impossible to make this work without
      templates. Instead, a new TypeBase class is introduced and all the
      structural (i.e., non-bitset) types inherit from it.
      
      The bitset type still requires the bit-munging hack and some nasty
      reinterpret-casts to pretend bitsets are of type Type*. Additionally,
      there is now the same hack for TypeBase - all pointers to the sub-types
      of TypeBase are reinterpret-casted to Type*. This is to keep the type
      constructors in inline method definitions (although it is unclear how
      much that actually buys us).
      
      In future, we would like to move to a model where we encapsulate Type*
      into a class (or possibly use Type where we used to use Type*). This
      would loosen the coupling between bitset size and pointer size, and
      eventually we would be able to have more bits.
      
      TBR=bradnelson@chromium.org
      
      Review URL: https://codereview.chromium.org/1655833002
      
      Cr-Commit-Position: refs/heads/master@{#33656}
      ef35f11c
  21. 27 Jan, 2016 1 commit
  22. 26 Jan, 2016 1 commit
    • jarin's avatar
      Replace HeapType with a non-templated FieldType class. · cfaeb63b
      jarin authored
      This replace HeapType with a dedicated class that implements just what we need for field type tracking. In the next CL, I plan to remove FieldType::Iterator because FieldType can iterate over at most one map.
      
      The ultimate plan is to get rid of templates in types.(h|cc) and remove type-inl.h.
      
      TBR=rossberg@chromium.org
      
      Review URL: https://codereview.chromium.org/1636013002
      
      Cr-Commit-Position: refs/heads/master@{#33521}
      cfaeb63b
  23. 25 Jan, 2016 1 commit
    • bmeurer's avatar
      [for-in] Further refactorings and unification around for-in. · 88f9995d
      bmeurer authored
      Cleanup %ForInPrepare runtime entry, and unify common logic with
      %ForInEnumerate (renamed from %GetPropertyNamesFast). Also introduce
      a TupleType to properly type JSForInPrepare and its projections w/o
      special hacks in the Typer. And fix %ForInNext and JSForInNext to be
      consistent with fullcodegen again (after the proxy refactorings last
      quarter).
      
      R=jarin@chromium.org
      BUG=v8:3650
      LOG=n
      
      Review URL: https://codereview.chromium.org/1631583002
      
      Cr-Commit-Position: refs/heads/master@{#33487}
      88f9995d
  24. 10 Nov, 2015 1 commit
  25. 05 Nov, 2015 1 commit
  26. 04 Nov, 2015 1 commit
    • bmeurer's avatar
      [types] Use unified integral representation bits. · 6471fbf7
      bmeurer authored
      We don't need to distinguish between signed and unsigned integral
      representations in the big boy type system. It actually even hurts
      in some cases. The representation is only about the way the values
      are mapped to bits in memory/registers, but the interpretation of
      the bits is specified by the semantic dimension.
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1416953006
      
      Cr-Commit-Position: refs/heads/master@{#31771}
      6471fbf7
  27. 30 Sep, 2015 1 commit
  28. 17 Sep, 2015 1 commit
  29. 15 Sep, 2015 1 commit
  30. 14 Sep, 2015 1 commit
  31. 03 Sep, 2015 1 commit
  32. 31 Aug, 2015 1 commit
  33. 21 Aug, 2015 1 commit
    • rossberg's avatar
      [simd] Introduce SIMD types (as classes) · a60f1922
      rossberg authored
      - Introduce a proper bit for SIMD primitive values.
      - Introduce constructors for individual SIMD types. These are currently just classes, which seems good enough for now, given that we always have exactly one global map per SIMD type.
      
      The only problem with using class types for SIMD is that a SIMD constant won't be a subtype of its specific type, only of the general SIMD type. But until we actually introduce SIMD constants into the compiler that shouldn't matter.
      
      R=jarin@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1303863002
      
      Cr-Commit-Position: refs/heads/master@{#30294}
      a60f1922
  34. 13 Aug, 2015 1 commit