1. 09 Jan, 2019 1 commit
  2. 08 Aug, 2018 1 commit
  3. 23 Jul, 2018 1 commit
  4. 16 Jul, 2018 1 commit
  5. 28 Mar, 2018 1 commit
  6. 23 Jan, 2018 1 commit
  7. 11 Dec, 2017 1 commit
    • Justin Ridgewell's avatar
      Implement DFA Unicode Decoder · cedec225
      Justin Ridgewell authored
      This is a separation of the DFA Unicode Decoder from
      https://chromium-review.googlesource.com/c/v8/v8/+/789560
      
      I attempted to make the DFA's table a bit more explicit in this CL. Still, the
      linter prevents me from letting me present the array as a "table" in source
      code. For a better representation, please refer to
      https://docs.google.com/spreadsheets/d/1L9STtkmWs-A7HdK5ZmZ-wPZ_VBjQ3-Jj_xN9c6_hLKA
      
      - - - - -
      
      Now for a big copy-paste from 789560:
      
      Essentially, reworks a standard FSM (imagine an
      array of structs) and flattens it out into a single-dimension array.
      Using Table 3-7 of the Unicode 10.0.0 standard (page 126 of
      http://www.unicode.org/versions/Unicode10.0.0/ch03.pdf), we can nicely
      map all bytes into one of 12 character classes:
      
      00. 0x00-0x7F
      01. 0x80-0x8F (split from general continuation because this range is not
          valid after a 0xF0 leading byte)
      02. 0x90-0x9F (split from general continuation because this range is not
          valid after a 0xE0 nor a 0xF4 leading byte)
      03. 0xA0-0xBF (the rest of the continuation range)
      04. 0xC0-0xC1, 0xF5-0xFF (the joined range of invalid bytes, notice this
          includes 255 which we use as a known bad byte during hex-to-int
              decoding)
      05. 0xC2-0xDF (leading bytes which require any continuation byte
          afterwards)
      06. 0xE0 (leading byte which requires a 0xA0-0xBF afterwards then any
          continuation byte after that)
      07. 0xE1-0xEC, 0xEE-0xEF (leading bytes which requires any continuation
          afterwards then any continuation byte after that)
      08. 0xED (leading byte which requires a 0x80-0x9F afterwards then any
          continuation byte after that)
      09. 0xF1-F3 (leading bytes which requires any continuation byte
          afterwards then any continuation byte then any continuation byte)
      10. 0xF0 (leading bytes which requires a 0x90-0xBF afterwards then any
          continuation byte then any continuation byte)
      11. 0xF4 (leading bytes which requires a 0x80-0x8F afterwards then any
          continuation byte then any continuation byte)
      
      Note that 0xF0 and 0xF1-0xF3 were swapped so that fewer bytes were
      needed to represent the transition state ("9, 10, 10, 10" vs.
      "10, 9, 9, 9").
      
      Using these 12 classes as "transitions", we can map from one state to
      the next. Each state is defined as some multiple of 12, so that we're
      always starting at the 0th column of each row of the FSM. From each
      state, we add the transition and get a index of the new row the FSM is
      entering.
      
      If at any point we encounter a bad byte, the state + bad-byte-transition
      is guaranteed to map us into the first row of the FSM (which contains no
      valid exiting transitions).
      
      The key differences from Björn's original (or his self-modified) DFA is
      the "bad" state is now mapped to 0 (or the first row of the FSM) instead
      of 12 (the second row). This saves ~50 bytes when gzipping, and also
      speeds up determining if a string is properly encoded (see his sample
      code at http://bjoern.hoehrmann.de/utf-8/decoder/dfa/#performance).
      
      Finally, I've replace his ternary check with an array access, to make
      the algorithm branchless. This places a requirement on the caller to 0
      out the code point between successful decodings, which it could always
      have done because it's already branching.
      
      R=marja@google.com
      
      Bug: 
      Change-Id: I574f208a84dc5d06caba17127b0d41f7ce1a3395
      Reviewed-on: https://chromium-review.googlesource.com/805357
      Commit-Queue: Justin Ridgewell <jridgewell@google.com>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarMathias Bynens <mathias@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50012}
      cedec225
  8. 02 Aug, 2017 1 commit
  9. 13 Feb, 2017 1 commit
  10. 05 Jul, 2016 1 commit
  11. 30 Jun, 2016 1 commit
  12. 20 Jun, 2016 1 commit
    • bmeurer's avatar
      [builtins] Introduce proper Float64Tan operator. · c87168bc
      bmeurer authored
      Import base::ieee754::tan() from fdlibm and introduce Float64Tan TurboFan
      operator based on that, similar to what we do for Float64Cos and Float64Sin.
      Rewrite Math.tan() as TurboFan builtin and use those operators to also
      inline Math.tan() into optimized TurboFan functions.
      
      Drive-by-fix: Kill the %_ConstructDouble intrinsics, and provide only
      the %ConstructDouble runtime entry for writing tests.
      
      BUG=v8:5086,v8:5126
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2083453002
      Cr-Commit-Position: refs/heads/master@{#37087}
      c87168bc
  13. 17 Jun, 2016 3 commits
  14. 16 Jun, 2016 3 commits
  15. 13 Jun, 2016 1 commit
    • 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
  16. 03 Jun, 2016 1 commit
    • 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
  17. 02 May, 2016 1 commit
  18. 30 Apr, 2016 2 commits
  19. 29 Apr, 2016 1 commit
  20. 25 Apr, 2016 1 commit
    • machenbach's avatar
      [build] Prepare moving v8.gyp to src/ · cb855fe7
      machenbach authored
      This will allow to pull in gyp as a deps to the same location
      as chromium (tools/gyp not build/gyp), needed for gn switch.
      
      This is the first step of a 3-way move.
      1) Copy v8.gyp in v8
      2) Update references in embedders (follow up)
      3) Remove old v8.gyp (follow up)
      
      BUG=chromium:474921
      LOG=n
      NOTRY=true
      
      Review URL: https://codereview.chromium.org/1920793002
      
      Cr-Commit-Position: refs/heads/master@{#35760}
      cb855fe7
  21. 09 Dec, 2015 1 commit
  22. 03 Nov, 2015 1 commit
  23. 02 Nov, 2015 5 commits
  24. 22 Oct, 2015 1 commit
  25. 16 Oct, 2015 1 commit
  26. 15 Oct, 2015 1 commit
  27. 30 Sep, 2015 1 commit
  28. 19 Aug, 2015 1 commit
  29. 20 Jul, 2015 1 commit
  30. 16 Jun, 2015 1 commit
  31. 01 Jun, 2015 1 commit