1. 12 Feb, 2019 1 commit
  2. 11 Feb, 2019 2 commits
  3. 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
  4. 30 Jan, 2019 1 commit
  5. 28 Jan, 2019 1 commit
  6. 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
  7. 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
  8. 21 Dec, 2018 1 commit
  9. 19 Dec, 2018 1 commit
  10. 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
  11. 07 Dec, 2018 3 commits
  12. 05 Dec, 2018 1 commit
  13. 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
  14. 28 Nov, 2018 1 commit
  15. 26 Nov, 2018 1 commit
  16. 19 Nov, 2018 1 commit
  17. 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
  18. 05 Nov, 2018 2 commits
  19. 25 Oct, 2018 1 commit
  20. 24 Oct, 2018 1 commit
  21. 23 Oct, 2018 2 commits
  22. 19 Oct, 2018 1 commit
  23. 10 Oct, 2018 1 commit
  24. 20 Sep, 2018 1 commit
  25. 15 Sep, 2018 1 commit
  26. 11 Sep, 2018 1 commit
  27. 22 Aug, 2018 1 commit
  28. 14 Aug, 2018 3 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
    • Leszek Swirski's avatar
      Revert "[turbofan] Further optimize DataView accesses." · 6a62d88e
      Leszek Swirski authored
      This reverts commit c46915b9.
      
      Reason for revert: Disasm failures https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20debug/21727 
      
      Original change's description:
      > [turbofan] Further optimize DataView accesses.
      > 
      > 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: I296170b828c2ccc1c317ed37840b564aa14cdec2
      > Reviewed-on: https://chromium-review.googlesource.com/1172777
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55099}
      
      TBR=sigurds@chromium.org,bmeurer@chromium.org
      
      Change-Id: If7a62e3a1a4ad26823fcbd2ab6eb4c053ad11c49
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:225811
      Reviewed-on: https://chromium-review.googlesource.com/1174171Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55107}
      6a62d88e
  29. 13 Aug, 2018 2 commits
  30. 07 Aug, 2018 1 commit
  31. 24 Jul, 2018 1 commit
    • Clemens Hammacher's avatar
      Reland "[turboassembler] Introduce hard-abort mode" · d324382e
      Clemens Hammacher authored
      This is a reland of a462a785
      
      Original change's description:
      > [turboassembler] Introduce hard-abort mode
      > 
      > For checks and assertions (mostly for debug code, like stack alignment
      > or zero extension), we had two modes: Emit a call to the {Abort}
      > runtime function (the default), and emit a debug break (used for
      > testing, enabled via --trap-on-abort).
      > In wasm, where we cannot just call a runtime function because code must
      > be isolate independent, we always used the trap-on-abort behaviour.
      > This causes problems for our fuzzers, which do not catch SIGTRAP, and
      > hence do not detect debug code failures.
      > 
      > This CL introduces a third mode ("hard abort"), which calls a C
      > function via {ExternalReference}. The C function still outputs the
      > abort reason, but does not print the stack trace. It then aborts via
      > "OS::Abort", just like the runtime function.
      > This will allow fuzzers to detect the crash and even find a nice error
      > message.
      > 
      > Even though this looks like a lot of code churn, it is actually not.
      > Most added lines are new tests, and other changes are minimal.
      > 
      > R=mstarzinger@chromium.org
      > 
      > Bug: chromium:863799
      > Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
      > Reviewed-on: https://chromium-review.googlesource.com/1142163
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54592}
      
      Bug: chromium:863799
      Change-Id: I7729a47b4823a982a8e201df36520aa2b6ef5326
      Reviewed-on: https://chromium-review.googlesource.com/1146100Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54656}
      d324382e