1. 13 Jun, 2016 2 commits
    • bmeurer's avatar
      [builtins] Introduce proper Float64Atan and Float64Atan2 operators. · 89d8c57b
      bmeurer authored
      Import base::ieee754::atan() and base::ieee754::atan2() from fdlibm and
      introduce Float64Atan and Float64Atan2 TurboFan operators based on those,
      similar to what we already did for Float64Log and Float64Log1p. Rewrite
      Math.atan() and Math.atan2() as TurboFan builtin and use the operators
      to also inline Math.atan() and Math.atan2() into optimized TurboFan functions.
      
      R=yangguo@chromium.org
      BUG=v8:5086,v8:5095
      
      Review-Url: https://codereview.chromium.org/2065503002
      Cr-Commit-Position: refs/heads/master@{#36916}
      89d8c57b
    • bmeurer's avatar
      [builtins] Introduce proper Float64Log1p operator. · 7ceed92a
      bmeurer authored
      Import base::ieee754::log1p() from fdlibm and introduce a Float64Log1p
      TurboFan operator based on that, similar to what we do for Float64Log.
      Rewrite Math.log1p() as TurboFan builtin and use that operator to also
      inline Math.log1p() into optimized TurboFan functions.
      
      Also unify the handling of the special IEEE 754 functions somewhat in
      the TurboFan backends. At some point we can hopefully express this
      completely in the InstructionSelector (once we have an idea what to do
      with the ST(0) return issue on IA-32/X87).
      
      Drive-by-fix: Add some more test coverage for the log function.
      
      R=yangguo@chromium.org
      BUG=v8:5086,v8:5092
      
      Review-Url: https://codereview.chromium.org/2060743002
      Cr-Commit-Position: refs/heads/master@{#36914}
      7ceed92a
  2. 09 Jun, 2016 1 commit
    • lpy's avatar
      Move hashmap into src/base. · 2fd55667
      lpy authored
      We ported hashmap.h into libsampler as a workaround before, so the main focus of
      this patch is to reduce code duplication. This patch moves the hashmap into
      src/base as well as creates DefaultAllocationPolicy using malloc and free.
      
      BUG=v8:5050
      LOG=n
      
      Review-Url: https://codereview.chromium.org/2010243003
      Cr-Commit-Position: refs/heads/master@{#36873}
      2fd55667
  3. 08 Jun, 2016 2 commits
  4. 07 Jun, 2016 3 commits
    • cbruni's avatar
      [dictionaries] Use IsKey(Isolate* i, Object* o) everywhere · 764d4e61
      cbruni authored
      Using the isolate to check for IsUndefined and IsTheHole is roughly at least
      20% faster in the worst-case and up to a factor 2x in the best case.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2031533002
      Cr-Commit-Position: refs/heads/master@{#36787}
      764d4e61
    • machenbach's avatar
      Revert of [builtins] Properly optimize TypedArray/DataView accessors.... · d3a43e47
      machenbach authored
      Revert of [builtins] Properly optimize TypedArray/DataView accessors. (patchset #3 id:40001 of https://codereview.chromium.org/2042013003/ )
      
      Reason for revert:
      Blink:
      https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/7296
      
      Original issue's description:
      > [builtins] Properly optimize TypedArray/DataView accessors.
      >
      > The following getters were moved to the TypedArray/DataView prototype
      > chain with ES2015, and hence need different treatment now:
      >
      > - DataView.prototype.buffer
      > - DataView.prototype.byteLength
      > - DataView.prototype.byteOffset
      > - TypedArray.prototype.buffer
      > - TypedArray.prototype.byteLength
      > - TypedArray.prototype.byteOffset
      > - TypedArray.prototype.length
      >
      > Instead of having special magic on the LoadIC in the IC system and the
      > optimizing compilers, as we used to do before (and which we got rid of
      > already), we just treat those as normal accessors and make them
      > recognizable via the BuiltinFunctionId mechanism. This allows us to
      > remove some of the additional magic from the IC subsystem, and just
      > extend the BuiltinFunctionId mechanism in Crankshaft slightly to cover
      > these cases too (TurboFan doesn't yet support accessors, but that will
      > be fixed soonish anyways).
      >
      > This addresses most of the 15-20% regression we saw on the Octane
      > GameBoy emulator benchmark.
      >
      > BUG=chromium:579905,chromium:593634,v8:4085,v8:5073
      > R=yangguo@chromium.org
      >
      > Committed: https://crrev.com/1ef737026565ea2becc84f30cfd432e581d50c6b
      > Cr-Commit-Position: refs/heads/master@{#36782}
      
      TBR=yangguo@chromium.org,bmeurer@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:579905,chromium:593634,v8:4085,v8:5073
      
      Review-Url: https://codereview.chromium.org/2039093005
      Cr-Commit-Position: refs/heads/master@{#36783}
      d3a43e47
    • bmeurer's avatar
      [builtins] Properly optimize TypedArray/DataView accessors. · 1ef73702
      bmeurer authored
      The following getters were moved to the TypedArray/DataView prototype
      chain with ES2015, and hence need different treatment now:
      
      - DataView.prototype.buffer
      - DataView.prototype.byteLength
      - DataView.prototype.byteOffset
      - TypedArray.prototype.buffer
      - TypedArray.prototype.byteLength
      - TypedArray.prototype.byteOffset
      - TypedArray.prototype.length
      
      Instead of having special magic on the LoadIC in the IC system and the
      optimizing compilers, as we used to do before (and which we got rid of
      already), we just treat those as normal accessors and make them
      recognizable via the BuiltinFunctionId mechanism. This allows us to
      remove some of the additional magic from the IC subsystem, and just
      extend the BuiltinFunctionId mechanism in Crankshaft slightly to cover
      these cases too (TurboFan doesn't yet support accessors, but that will
      be fixed soonish anyways).
      
      This addresses most of the 15-20% regression we saw on the Octane
      GameBoy emulator benchmark.
      
      BUG=chromium:579905,chromium:593634,v8:4085,v8:5073
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2042013003
      Cr-Commit-Position: refs/heads/master@{#36782}
      1ef73702
  5. 06 Jun, 2016 1 commit
  6. 03 Jun, 2016 2 commits
    • bmeurer's avatar
      [json] Repair JSON.parse regression with non-sequential strings. · e3c3be36
      bmeurer authored
      Make sure to flatten strings first in JSON.parse() builtins, otherwise
      we always hit the slow path for non-sequential strings, i.e. for cons
      strings.
      
      Also don't create any arguments adaptor frames for JSON.parse() as the
      C++ builtin can handle any number of inputs properly.
      
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2039553002
      Cr-Commit-Position: refs/heads/master@{#36722}
      e3c3be36
    • bmeurer's avatar
      [builtins] Migrate Math.log to TurboFan. · f2da19fe
      bmeurer authored
      Introduce a dedicated Float64Log machine operator, that is either
      implemented by a direct C call or by platform specific code, i.e.
      using the FPU on x64 and ia32.
      
      This operator is used to implement Math.log as a proper TurboFan
      builtin on top of the CodeStubAssembler.
      
      Also introduce a NumberLog simplified operator on top of Float64Log
      and use that for the fast inline path of Math.log inside TurboFan
      optimized code.
      
      BUG=v8:5065
      
      Review-Url: https://codereview.chromium.org/2029413005
      Cr-Commit-Position: refs/heads/master@{#36703}
      f2da19fe
  7. 01 Jun, 2016 1 commit
  8. 31 May, 2016 2 commits
  9. 30 May, 2016 2 commits
  10. 27 May, 2016 3 commits
    • littledan's avatar
      Improve strictness of Annex B 3.3 for generators and async functions · 6390282f
      littledan authored
      Annex B 3.3 applies only for ordinary FunctionDeclarations, not
      GeneratorDeclarations or AsyncFunctionDeclarations. This patch
      - Skips applying Annex B 3.3 to async functions
      - Adds a flag to refrain from applying it to generators
      - UseCounter for how often duplicate function in block occurs
        with generators (unclear how to measure need for hoisting from block)
      
      BUG=v8:4806
      
      Review-Url: https://codereview.chromium.org/1995863002
      Cr-Commit-Position: refs/heads/master@{#36557}
      6390282f
    • bmeurer's avatar
      [builtins] Migrate String.prototype.trim/trimLeft/trimRight to C++. · c3ffc92d
      bmeurer authored
      These builtins do call into C++ anyways, so there's no point in keeping
      the JavaScript wrappers for them.
      
      R=franzih@chromium.org
      BUG=v8:5049
      
      Review-Url: https://codereview.chromium.org/2018963002
      Cr-Commit-Position: refs/heads/master@{#36553}
      c3ffc92d
    • franzih's avatar
      [builtins] Rewrite uri.js as builtin functions. · 8c31bd81
      franzih authored
      Rewrite decodeURI and decodeURIComponent as builtin functions
      and install them in the bootstrapper.
      
      Delete unused runtime functions:
       - TruncateString
       - NewString
       - OneByteSeqStringGetChar
       - OneByteSeqStringSetChar
       - TwoByteSeqStringGetChar
       - TwoByteSeqStringSetChar
      
      Add regression test for decoding large strings. Clusterfuzz detected
      a problem with %TruncateString, see
      https://bugs.chromium.org/p/chromium/issues/detail?id=612109#c6
      This is automatically fixed by this rewrite because %TruncateString
      is deleted anyways.
      
      Crude benchmark on 585 decodeURI and decodeURIComponent tests
      averaged over five runs:
      
      * builtin functions
      real	0m9.69s
      user	2m39.8816s
      sys    	0m12.6398s
      
      * JS functions calling into the runtime e.g., for %TruncateString
      real	0m11.0598s
      user	3m6.7026s
      sys	0m13.5756s
      
      By running:
      $  time tools/run-tests.py   --arch=x64  --mode=Release --buildbot
        test262/built-ins/decodeURI* mjsunit/uri
      >>> Running tests for x64.Release
      
      BUG=v8:4912, chromium:612109
      R=yangguo@chromium.org, bmeurer@chromium.org
      
      Review-Url: https://codereview.chromium.org/1994733003
      Cr-Commit-Position: refs/heads/master@{#36543}
      8c31bd81
  11. 25 May, 2016 4 commits
  12. 21 May, 2016 1 commit
    • bmeurer's avatar
      [builtins] Migrate String.fromCharCode to C++. · cc71837f
      bmeurer authored
      The previous JavaScript version created way too many ConsStrings for
      longer strings, i.e. when using String.fromCharCode together with
      Function.prototype.apply and arrays of char codes.
      
      This version now always allocates sequential strings and therefore uses
      way less memory when turning longer character sequences into strings,
      and therefore fixes the memory regression on Google Maps.
      
      BUG=chromium:609831
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2004733002
      Cr-Commit-Position: refs/heads/master@{#36427}
      cc71837f
  13. 20 May, 2016 1 commit
  14. 19 May, 2016 3 commits
  15. 18 May, 2016 2 commits
  16. 17 May, 2016 3 commits
    • bmeurer's avatar
      [es6] Reintroduce the instanceof operator in the backends. · 551e0aa1
      bmeurer authored
      This adds back the instanceof operator support in the backends and
      introduces a @@hasInstance protector cell on the isolate that guards the
      fast path for the InstanceOfStub. This way we recover the ~10%
      regression on Octane EarleyBoyer in Crankshaft and greatly improve
      TurboFan and Ignition performance of instanceof.
      
      R=ishell@chromium.org
      TBR=hpayer@chromium.org,rossberg@chromium.org
      BUG=chromium:597249, v8:4447
      LOG=n
      
      Review-Url: https://codereview.chromium.org/1980483003
      Cr-Commit-Position: refs/heads/master@{#36275}
      551e0aa1
    • franzih's avatar
      [builtins] Move EncodeURI from runtime to builtins. · c60cb90c
      franzih authored
      Repackage encodeURI and encodeURIComponent as builtin functions
      and install them in the bootstrapper.
      
      Crude benchmark on 351 encodeURI and encodeURIComponent tests averaged
      over five runs:
      
      * builtin functions
      real	0m8.01s
      user	0m18.00s
      sys	0m7.37s
      
      * JS functions calling into the runtime e.g., for %NewString
      real	0m8.44s
      user	0m19.52s
      sys	0m7.49s
      
      By running:
      $ time tools/run-tests.py   --arch=x64 --mode=Release --buildbot
      mjsunit/uri test262/built-ins/encodeURI*
      >>> Running tests for x64.Release
      
      BUG=v8:4912
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/1983593002
      Cr-Commit-Position: refs/heads/master@{#36273}
      c60cb90c
    • caitpotter88's avatar
      [esnext] prototype runtime implementation for async functions · d08c0304
      caitpotter88 authored
      BUG=v8:4483
      LOG=N
      R=littledan@chromium.org, adamk@chromium.org
      
      Review-Url: https://codereview.chromium.org/1895603002
      Cr-Commit-Position: refs/heads/master@{#36263}
      d08c0304
  17. 16 May, 2016 1 commit
  18. 13 May, 2016 1 commit
  19. 12 May, 2016 2 commits
  20. 11 May, 2016 1 commit
    • jshin's avatar
      Use ICU case conversion/transliterator for case conversion · b348d47b
      jshin authored
      When I18N is enabled, use ICU's case conversion API and transliteration
      API [1] to implement String.prototype.to{Upper,Lower}Case and
      String.prototype.toLocale{Upper,Lower}Case.
      
      * ICU-based case conversion was implemented in runtime-i18n.cc/i18n.js
      * The above 4 functions are overridden with those in i18n.js when
        --icu_case_mapping flag is turned on. To control the override by the flag,
        they're overriden in icu-case-mapping.js
      
      Previously, toLocale{U,L}Case just called to{U,L}Case so that they didn't
      support locale-sensitive case conversion for Turkic languages (az, tr),
      Greek (el) and Lithuanian (lt).
      
      Before ICU APIs for the most general case are called, a fast-path for Latin-1
      is tried. It's taken from Blink and adopted as necessary. This fast path
      is always tried for to{U,L}Case. For toLocale{U,L}Case, it's only taken
      when a locale (explicitly specified or default) is not in {az, el, lt, tr}.
      
      With these changes, a build with --icu_case_mapping=true passes a bunch
      of tests in test262/intl402/Strings/* and intl/* that failed before.
      
      Handling of pure ASCII strings (aligned at word boundary) are not as fast
      as Unibrow's implementation that uses word-by-word case conversion. OTOH,
      Latin-1 input handling is faster than Unibrow. General Unicode input
      handling is slower but more accurate.
      
      See https://docs.google.com/spreadsheets/d/1KJCJxKc1FxFXjwmYqABS0_2cNdPetvnd8gY8_HGSbrg/edit?usp=sharing for the benchmark.
      
      This CL started with http://crrev.com/1544023002#ps200001 by littledan@,
      but has changed significantly since.
      
      [1] See why transliteration API is needed for uppercasing in Greek.
          http://bugs.icu-project.org/trac/ticket/10582
      
      R=yangguo
      BUG=v8:4476,v8:4477
      LOG=Y
      TEST=test262/{built-ins,intl402}/Strings/*, webkit/fast/js/*, mjsunit/string-case,
           intl/general/case*
      
      Review-Url: https://codereview.chromium.org/1812673005
      Cr-Commit-Position: refs/heads/master@{#36187}
      b348d47b
  21. 09 May, 2016 1 commit
    • gsathya's avatar
      Fix TypedArray Property optimizations · 41d571df
      gsathya authored
      This patch installs %TypedArray% and its prototype on the native
      context, and wires them up to each TypedArray subclass. This is later
      used to check the holder of length, byteLength and byteOffset is
      %Typedarray% and apply the appropriate optimizations.
      
      BUG=chromium:593634
      LOG=Y
      
      Review-Url: https://codereview.chromium.org/1949863002
      Cr-Commit-Position: refs/heads/master@{#36116}
      41d571df
  22. 03 May, 2016 1 commit