1. 25 Mar, 2019 2 commits
  2. 08 Mar, 2019 1 commit
  3. 05 Mar, 2019 1 commit
  4. 25 Feb, 2019 1 commit
    • Benedikt Meurer's avatar
      [objects] Free one bit in the SharedFunctionInfo::flags. · 591408cb
      Benedikt Meurer authored
      We'll need one bit in the SharedFunctionInfo::flags to record whether
      it's safe to skip arguments adaptor frames (for v8:8895), so this
      just removes the SharedFunctionInfo::IsDerivedConstructorBit which is
      redundant, since the same information is already available in the
      SharedFunctionInfo::FunctionKindBits, and most places in the code
      use that already, with the exception of the JSConstructStubGeneric
      builtin.
      
      This changes the JSConstructStubGeneric builtin to just check the
      function kind instead of testing the explicit bit, which also makes
      this more consistent. It seems like there's not much overhead to
      that, doing an additional bitmasking plus two comparisons instead
      of one. This shouldn't really matter since invocation and execution
      of the constructors is going to dominate and optimized code inlines
      all of this anyways. If this turns out to affect performance, we
      can still look into encoding the FunctionKindBits more cleverly.
      
      Drive-by-fix: Move the FunctionKindBits first in the flags to avoid
      the shift when accessing the function kind. This seems logic, since
      for the actual boolean bit fields it doesn't matter where they are
      in the flags, whereas for the function kind this saves one shift.
      
      Bug: v8:8834, v8:8895
      Change-Id: I184a8f5cc5c140bdc272cf9a5ad546093c457306
      Reviewed-on: https://chromium-review.googlesource.com/c/1482915Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59821}
      591408cb
  5. 12 Feb, 2019 1 commit
  6. 11 Feb, 2019 2 commits
  7. 07 Feb, 2019 1 commit
    • deepak1556's avatar
      DISALLOW_IMPLICIT_CONSTRUCTORS for MacroAssembler · 9e060e47
      deepak1556 authored
      When BUILDING_V8_SHARED in release builds __declspec(dllexport)
      causes generation of implicit constructors in the forwarding class
      while its deleted in TurboAssemblerBase, which leads to compilation
      errors like:
      
      In file included from gen/v8/v8_base_jumbo_6.cc:41:
      In file included from .\../../v8/src/interface-descriptors.cc:7:
      In file included from ../../v8\src/macro-assembler.h:40:
      ../../v8\src/x64/macro-assembler-x64.h(92,9):  error: call to deleted constructor of 'v8::internal::TurboAssemblerBase'
            : TurboAssemblerBase(std::forward<Args>(args)...) {}
              ^                  ~~~~~~~~~~~~~~~~~~~~~~~~
      ../../v8\src/x64/macro-assembler-x64.h(536,25):  note: in instantiation of function template specialization 'v8::internal::TurboAssembler::TurboAssembler<v8::internal::TurboAssembler>' requested here
      class V8_EXPORT_PRIVATE MacroAssembler : public TurboAssembler {
                              ^
      ../../v8\src/turbo-assembler.h(127,34):  note: 'TurboAssemblerBase' has been explicitly marked deleted here
        DISALLOW_IMPLICIT_CONSTRUCTORS(TurboAssemblerBase);
                                       ^
      1 error generated.
      
      The original changes were made in https://chromium-review.googlesource.com/c/v8/v8/+/1414913
      
      R=mstarzinger@chromium.org,jgruber@chromium.org,clemensh@chromium.org
      
      Bug: NONE
      Change-Id: I87a5a678b8bae13b3adc6f1c6ac0b9313ed18d85
      Reviewed-on: https://chromium-review.googlesource.com/c/1454676
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59427}
      9e060e47
  8. 30 Jan, 2019 1 commit
  9. 28 Jan, 2019 1 commit
  10. 17 Jan, 2019 1 commit
    • Clemens Hammacher's avatar
      Use forwarding constructors for MacroAssembler · edab9a20
      Clemens Hammacher authored
      and TurboAssembler. Instead of listing all the different combinations
      of arguments (which is one more now, temporarily), just forward all
      arguments down via MacroAssembler and TurboAssembler to
      TurboAssemblerBase.
      Interestingly, this requires more specific types sometimes (int instead
      of size_t), since further down the forwarding chain, the compiler does
      not recognize any more that the value is a constant, and emits a
      warning about a possibly truncating implicit conversion.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:8689, v8:8562
      Change-Id: Ifd13d2210ee64251c0075c0d9b68cacd5107d9ab
      Reviewed-on: https://chromium-review.googlesource.com/c/1414913Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58869}
      edab9a20
  11. 08 Jan, 2019 1 commit
    • Ross McIlroy's avatar
      [Deopt] Remove jump table in prologue of deopt entries. · 4ab96a9a
      Ross McIlroy authored
      Remove the use of a jump table in the prologue of the deopt entries
      and instead pass the bailout id explicitly in a register when calling
      the deopt entry routine from optimized code. This unifies the logic
      with the way the Arm64 code works. It saves the following amount of
      memory in code stubs:
      
       - arm:  384KB
       - ia32: 480KB
       - x64:  240KB
      
      This could be offset by a slight increase in the size of optimized code
      for loading the immediate, however this impact should be minimal and
      will scale with the maximum number of bailout ids (e.g., the size of
      code will increase by one instruction per bailout id on Arm, therefore
      ~98,000 bailouts will be needed before the overhead is greater than
      the current fixed table size).
      
      Change-Id: I838604b48fa04cbd45320c7b9dac0de08fd8eb25
      Reviewed-on: https://chromium-review.googlesource.com/c/1398224
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58636}
      4ab96a9a
  12. 21 Dec, 2018 1 commit
  13. 19 Dec, 2018 1 commit
  14. 17 Dec, 2018 1 commit
    • Jakob Gruber's avatar
      [nojit] Add a kCallBuiltinPointer call kind · f323a5f4
      Jakob Gruber authored
      Currently, Torque's builtin pointers store a Code target underneath and
      callsites generate a kArchCallCodeObject opcode. When embedded builtins
      are enabled, the call thus first calls the on-heap trampoline, which
      finally jumps to the target off-heap builtin code.
      
      This will no longer be possible in jitless mode, since on-heap code must
      not be executable.
      
      As a step towards changing the way builtin pointers are called
      (function pointers will hold the builtin index as a Smi, and callsites
      look up the off-heap target address and jump there), this CL adds a
      dedicated opcode for builtin pointer calls to the compiler pipeline.
      
      The calling mechanism itself is unchanged, changes there will happen
      in a follow-up.
      
      Drive-by: rename 'FunctionPointer' in torque/ to 'BuiltinPointer'.
      
      Bug: v8:7777
      Change-Id: Ic999a1cd7c3172425dd4a1513ae2f50c774faddb
      Reviewed-on: https://chromium-review.googlesource.com/c/1378175Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58281}
      f323a5f4
  15. 07 Dec, 2018 3 commits
  16. 05 Dec, 2018 1 commit
  17. 29 Nov, 2018 2 commits
    • Andreas Haas's avatar
      Reland: [wasm] Add more unit tests for trap handler · 3d2bc5d0
      Andreas Haas authored
      The problem were missing V8_EXPORT_PRIVATE and V8_EXPORT.
      
      The unittests test if the trap handler only handles those traps it
      is supposed to handle:
      * Only handle traps when the thread-in-wasm flag is set.
      * Only handle traps of the right type, i.e. memory access violations.
      * Only handle traps at recorded instructions.
      
      The tests also test the consistency of the thread-in-wasm flag. I made
      one change in the trap handler where that consistency could be
      violated.
      
      All tests are executed with the default trap handler provided by V8,
      and with the trap handler callback installed in a test signal/exception
      handler.
      
      Patchset 1 is the original CL.
      
      R=mstarzinger@chromium.org
      
      Change-Id: I172d94f24cdba4c3a1f7f344825b059dbb59da79
      Reviewed-on: https://chromium-review.googlesource.com/c/1351024Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57947}
      3d2bc5d0
    • Jakob Kummerow's avatar
      [ubsan] Be more explicit about casting ObjectPtr · eee67af3
      Jakob Kummerow authored
      Explicitly disallow implicit casting of ObjectPtr to bool to match
      clang's and MSVC's behavior.
      Introduce a few function overloads using ObjectPtr instead of Object*.
      Fix printing of ObjectPtr for objects-printer.cc and GTest.
      
      Bug: v8:3770
      Change-Id: I3c3580d363ae6d9fe8f743c6151abc11a915f05c
      Reviewed-on: https://chromium-review.googlesource.com/c/1351245
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57928}
      eee67af3
  18. 28 Nov, 2018 1 commit
  19. 26 Nov, 2018 1 commit
  20. 19 Nov, 2018 1 commit
  21. 16 Nov, 2018 1 commit
    • Clemens Hammacher's avatar
      [iwyu] Ensure that macro assembler includes happen correctly · 1952f928
      Clemens Hammacher authored
      The platform specific macro assembler headers can not be included
      directly. They require symbols declared in macro-assembler.h.
      We also cannot include macro-assembler.h from the platform specific
      headers, because that would form a cycle, and the include in
      macro-assembler.h would be skipped, which then also fails.
      
      This CL documents and enforces this unfortunate situation.
      This helps with further iwyu cleanups.
      
      Note that current code which includes the platform specific headers
      only works because we transitively included macro-assembler.h already
      before.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:8238, v8:7490
      Change-Id: I2dc65ad950400941406e1f2f8969d0d15f524bf8
      Reviewed-on: https://chromium-review.googlesource.com/c/1340240
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57578}
      1952f928
  22. 05 Nov, 2018 2 commits
  23. 25 Oct, 2018 1 commit
  24. 24 Oct, 2018 1 commit
  25. 23 Oct, 2018 2 commits
  26. 19 Oct, 2018 1 commit
  27. 10 Oct, 2018 1 commit
  28. 20 Sep, 2018 1 commit
  29. 15 Sep, 2018 1 commit
  30. 11 Sep, 2018 1 commit
  31. 22 Aug, 2018 1 commit
  32. 14 Aug, 2018 2 commits
    • Georgia Kouveli's avatar
      [arm64] Clean up of move operations. · de3f3cf0
      Georgia Kouveli authored
      * Perform the lookups into the builtins constant table and external reference
        table in the generic version of Mov that accepts an Operand source. This
        makes sure we do not miss looking up constants and external references when
        the generic Mov is called.
      * Remove Mov(ExternalReference) as ExternalReference can be implicitly converted
        to an Operand.
      * Remove two Move functions that are unused in architecture-independent code.
        Replace their uses in arm64-specific code with the generic Mov, which does all
        the necessary work now.
      
      Change-Id: Ibbcee6ba22f661984cd830717e14c9b35a1fba0a
      Reviewed-on: https://chromium-review.googlesource.com/1172351
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55121}
      de3f3cf0
    • Benedikt Meurer's avatar
      [turbofan] Further optimize DataView accesses. · 5fecd146
      Benedikt Meurer authored
      This adds support for unaligned load/store access to the DataView
      backing store and uses byteswap operations to fix up the endianess
      when necessary. This changes the Word32ReverseBytes operator to be
      a required operator and adds the missing support on the Intel and
      ARM platforms (on 64-bit platforms the Word64ReverseBytes operator
      is also mandatory now).
      
      This further improves the performance on the dataviewperf.js test
      mentioned in the tracking bug by up to 40%, and at the same time
      reduces the code complexity in the EffectControlLinearizer.
      
      Bug: chromium:225811
      Change-Id: I7c1ec826faf46a144a5a9068f8f815a5fd040997
      Reviewed-on: https://chromium-review.googlesource.com/1174252Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55111}
      5fecd146