1. 15 Oct, 2020 3 commits
    • Georg Neis's avatar
      Revert "[compiler, heap] Create LocalHeap outside of ExecuteJob" · 04c85d7c
      Georg Neis authored
      This reverts commit 44708a5b.
      
      Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/33692
      
      Original change's description:
      > [compiler, heap] Create LocalHeap outside of ExecuteJob
      >
      > Create LocalHeap directly in the Task or in GetOptimizedCodeNow and
      > pass its reference as argument to ExecuteJob. This allows us to create
      > LocalHeap differently for the main and background thread, e.g. by
      > passing an additional argument to the constructor in the future.
      > It will be required in the future anyways when the main thread will
      > have its own LocalHeap/LocalIsolate.
      >
      > Extending the scope of LocalHeap, also made
      > HandleBase::IsDereferenceAllowed more precise and uncovered two
      > potential issues: heap accesses in
      > OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode
      > with --code-comments.
      >
      > LocalHeap can now be created in the parked state. Also fixed a data
      > race with LocalHeap's destructor publishing write barrier entries
      > without holding the lock.
      >
      > Bug: v8:10315
      > Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70521}
      
      TBR=ulan@chromium.org,neis@chromium.org,leszeks@chromium.org,solanes@chromium.org,dinfuehr@chromium.org
      
      Change-Id: I9dd1f8ca6237d5716b6d8938cef0ee3f642f3166
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10315
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474118Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70522}
      04c85d7c
    • Dominik Inführ's avatar
      [compiler, heap] Create LocalHeap outside of ExecuteJob · 44708a5b
      Dominik Inführ authored
      Create LocalHeap directly in the Task or in GetOptimizedCodeNow and
      pass its reference as argument to ExecuteJob. This allows us to create
      LocalHeap differently for the main and background thread, e.g. by
      passing an additional argument to the constructor in the future.
      It will be required in the future anyways when the main thread will
      have its own LocalHeap/LocalIsolate.
      
      Extending the scope of LocalHeap, also made
      HandleBase::IsDereferenceAllowed more precise and uncovered two
      potential issues: heap accesses in
      OptimizingCompileDispatcher::CompileNext and PipelineImpl::AssembleCode
      with --code-comments.
      
      LocalHeap can now be created in the parked state. Also fixed a data
      race with LocalHeap's destructor publishing write barrier entries
      without holding the lock.
      
      Bug: v8:10315
      Change-Id: I9226972601a07b87108cd66efbbb6a0d118af58d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460818
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70521}
      44708a5b
    • Ng Zhi An's avatar
      [x64] Add movlps and movhps to assembler · 944dad59
      Ng Zhi An authored
      These instructions will be used for prototyping Wasm SIMD's store lane
      later on, separated the implementation for assembler and disassembler
      into this patch to make things smaller.
      
      Curiously, movhps and movlhps seems to have the same encoding, 0f 16, so
      I'm not sure not sure how to differentiate them in the disassembler
      besides using the mod field, since movlhps only takes xmm registers,
      whereas movhps always take 1 operand.
      
      Bug: v8:10975
      Change-Id: I8be9a31b1c9a5515038f9c8c55ef30d1ba063ea7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2471977Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70520}
      944dad59
  2. 14 Oct, 2020 5 commits
  3. 13 Oct, 2020 4 commits
    • Igor Sheludko's avatar
      Reland^2 "[csa] Fix semantics of PopAndReturn" · d2ab873d
      Igor Sheludko authored
      This is a reland of 3593ee83
      
      The MSAN doesn't seem to be considering initializing stores via inline
      assembly as such (in a new cctest helper GetStackPointer()), so this
      reland attempt fixes the issue and ensures that the MSAN bot is happy.
      
      Original change's description:
      > Reland "[csa] Fix semantics of PopAndReturn"
      >
      > This is a reland of 5e5eaf79
      >
      > This CL fixes the "function returns address of local variable" issue
      > which GCC was complaining about by using inline assembly instead of
      > address of a local for getting stack pointer approximation.
      >
      > Original change's description:
      > > [csa] Fix semantics of PopAndReturn
      > >
      > > This CL prohibits using PopAndReturn from the builtins that
      > > have calling convention with arguments on the stack.
      > >
      > > This CL also updates the PopAndReturn tests so that even off-by-one
      > > errors in the number of poped arguments are caught which was not the
      > > case before.
      > >
      > > Motivation:
      > >
      > > PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
      > > dropping ALL JS arguments that are currently located on the stack.
      > > Disallowing PopAndReturn in builtins with stack arguments simplifies
      > > semantics of this instruction because in case of presence of declared
      > > stack parameters it's impossible to distinguish the following cases:
      > > 1) stack parameter is included in JS arguments (and therefore it will
      > >    be dropped as a part of 'pop' number of arguments),
      > > 2) stack parameter is NOT included in JS arguments (and therefore it
      > >    should be dropped in ADDITION to the 'pop' number of arguments).
      > >
      > > This issue wasn't noticed before because builtins with stack parameters
      > > relied on adapter frames machinery to ensure that the expected
      > > parameters are present on the stack, but on the same time the adapter
      > > frame tearing down code was effectively recovering the stack pointer
      > > potentially broken by the CSA builtin.
      > >
      > > Once we get rid of the arguments adapter frames keeping stack pointer
      > > in a valid state becomes crucial.
      > >
      > > Bug: v8:5269, v8:10201
      > > Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
      > > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#70454}
      >
      > Tbr: tebbi@chromium.org
      > Bug: v8:5269
      > Bug: v8:10201
      > Change-Id: Ic1a05fcc4efd2068538bff28189545cfd2617d9b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465839
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Victor Gomes <victorgomes@chromium.org>
      > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70483}
      
      Tbr: tebbi@chromium.org
      Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel_ng
      Bug: v8:5269
      Bug: v8:10201
      Change-Id: Ib09af2d1260bb42ac26aabface14e6b83b3efec4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467847
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70492}
      d2ab873d
    • Clemens Backes's avatar
      Revert "Reland "[csa] Fix semantics of PopAndReturn"" · c40b2b7e
      Clemens Backes authored
      This reverts commit 3593ee83.
      
      Reason for revert: MSan issues: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/34798
      
      Original change's description:
      > Reland "[csa] Fix semantics of PopAndReturn"
      >
      > This is a reland of 5e5eaf79
      >
      > This CL fixes the "function returns address of local variable" issue
      > which GCC was complaining about by using inline assembly instead of
      > address of a local for getting stack pointer approximation.
      >
      > Original change's description:
      > > [csa] Fix semantics of PopAndReturn
      > >
      > > This CL prohibits using PopAndReturn from the builtins that
      > > have calling convention with arguments on the stack.
      > >
      > > This CL also updates the PopAndReturn tests so that even off-by-one
      > > errors in the number of poped arguments are caught which was not the
      > > case before.
      > >
      > > Motivation:
      > >
      > > PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
      > > dropping ALL JS arguments that are currently located on the stack.
      > > Disallowing PopAndReturn in builtins with stack arguments simplifies
      > > semantics of this instruction because in case of presence of declared
      > > stack parameters it's impossible to distinguish the following cases:
      > > 1) stack parameter is included in JS arguments (and therefore it will
      > >    be dropped as a part of 'pop' number of arguments),
      > > 2) stack parameter is NOT included in JS arguments (and therefore it
      > >    should be dropped in ADDITION to the 'pop' number of arguments).
      > >
      > > This issue wasn't noticed before because builtins with stack parameters
      > > relied on adapter frames machinery to ensure that the expected
      > > parameters are present on the stack, but on the same time the adapter
      > > frame tearing down code was effectively recovering the stack pointer
      > > potentially broken by the CSA builtin.
      > >
      > > Once we get rid of the arguments adapter frames keeping stack pointer
      > > in a valid state becomes crucial.
      > >
      > > Bug: v8:5269, v8:10201
      > > Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
      > > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#70454}
      >
      > Tbr: tebbi@chromium.org
      > Bug: v8:5269
      > Bug: v8:10201
      > Change-Id: Ic1a05fcc4efd2068538bff28189545cfd2617d9b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465839
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Victor Gomes <victorgomes@chromium.org>
      > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70483}
      
      TBR=tebbi@chromium.org,ishell@chromium.org,victorgomes@chromium.org
      
      Change-Id: Icbd71d744a519a58e49feb917109228631b9d9a3
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:5269
      Bug: v8:10201
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467846Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70485}
      c40b2b7e
    • Igor Sheludko's avatar
      Reland "[csa] Fix semantics of PopAndReturn" · 3593ee83
      Igor Sheludko authored
      This is a reland of 5e5eaf79
      
      This CL fixes the "function returns address of local variable" issue
      which GCC was complaining about by using inline assembly instead of
      address of a local for getting stack pointer approximation.
      
      Original change's description:
      > [csa] Fix semantics of PopAndReturn
      >
      > This CL prohibits using PopAndReturn from the builtins that
      > have calling convention with arguments on the stack.
      >
      > This CL also updates the PopAndReturn tests so that even off-by-one
      > errors in the number of poped arguments are caught which was not the
      > case before.
      >
      > Motivation:
      >
      > PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
      > dropping ALL JS arguments that are currently located on the stack.
      > Disallowing PopAndReturn in builtins with stack arguments simplifies
      > semantics of this instruction because in case of presence of declared
      > stack parameters it's impossible to distinguish the following cases:
      > 1) stack parameter is included in JS arguments (and therefore it will
      >    be dropped as a part of 'pop' number of arguments),
      > 2) stack parameter is NOT included in JS arguments (and therefore it
      >    should be dropped in ADDITION to the 'pop' number of arguments).
      >
      > This issue wasn't noticed before because builtins with stack parameters
      > relied on adapter frames machinery to ensure that the expected
      > parameters are present on the stack, but on the same time the adapter
      > frame tearing down code was effectively recovering the stack pointer
      > potentially broken by the CSA builtin.
      >
      > Once we get rid of the arguments adapter frames keeping stack pointer
      > in a valid state becomes crucial.
      >
      > Bug: v8:5269, v8:10201
      > Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
      > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70454}
      
      Tbr: tebbi@chromium.org
      Bug: v8:5269
      Bug: v8:10201
      Change-Id: Ic1a05fcc4efd2068538bff28189545cfd2617d9b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465839Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70483}
      3593ee83
    • Zhao Jiazhong's avatar
      [mips] Fix DropAndRet with a frame that larger than int16_max · 82a8bfdf
      Zhao Jiazhong authored
      Change-Id: I3f5dbb0fbae3862a6da4146b83e49986c8be3bdc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467015Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
      Cr-Commit-Position: refs/heads/master@{#70469}
      82a8bfdf
  4. 12 Oct, 2020 3 commits
    • Zhi An Ng's avatar
      Revert "[csa] Fix semantics of PopAndReturn" · d813f56c
      Zhi An Ng authored
      This reverts commit 5e5eaf79.
      
      Reason for revert: Failure on V8 Linux gcc https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/8929?
      
      Original change's description:
      > [csa] Fix semantics of PopAndReturn
      >
      > This CL prohibits using PopAndReturn from the builtins that
      > have calling convention with arguments on the stack.
      >
      > This CL also updates the PopAndReturn tests so that even off-by-one
      > errors in the number of poped arguments are caught which was not the
      > case before.
      >
      > Motivation:
      >
      > PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
      > dropping ALL JS arguments that are currently located on the stack.
      > Disallowing PopAndReturn in builtins with stack arguments simplifies
      > semantics of this instruction because in case of presence of declared
      > stack parameters it's impossible to distinguish the following cases:
      > 1) stack parameter is included in JS arguments (and therefore it will
      >    be dropped as a part of 'pop' number of arguments),
      > 2) stack parameter is NOT included in JS arguments (and therefore it
      >    should be dropped in ADDITION to the 'pop' number of arguments).
      >
      > This issue wasn't noticed before because builtins with stack parameters
      > relied on adapter frames machinery to ensure that the expected
      > parameters are present on the stack, but on the same time the adapter
      > frame tearing down code was effectively recovering the stack pointer
      > potentially broken by the CSA builtin.
      >
      > Once we get rid of the arguments adapter frames keeping stack pointer
      > in a valid state becomes crucial.
      >
      > Bug: v8:5269, v8:10201
      > Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
      > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70454}
      
      TBR=tebbi@chromium.org,ishell@chromium.org
      
      Change-Id: I2673982a8f51cbecf421af11b0ce5ad5031fb406
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:5269
      Bug: v8:10201
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465656Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70458}
      d813f56c
    • Igor Sheludko's avatar
      [csa] Fix semantics of PopAndReturn · 5e5eaf79
      Igor Sheludko authored
      This CL prohibits using PopAndReturn from the builtins that
      have calling convention with arguments on the stack.
      
      This CL also updates the PopAndReturn tests so that even off-by-one
      errors in the number of poped arguments are caught which was not the
      case before.
      
      Motivation:
      
      PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for
      dropping ALL JS arguments that are currently located on the stack.
      Disallowing PopAndReturn in builtins with stack arguments simplifies
      semantics of this instruction because in case of presence of declared
      stack parameters it's impossible to distinguish the following cases:
      1) stack parameter is included in JS arguments (and therefore it will
         be dropped as a part of 'pop' number of arguments),
      2) stack parameter is NOT included in JS arguments (and therefore it
         should be dropped in ADDITION to the 'pop' number of arguments).
      
      This issue wasn't noticed before because builtins with stack parameters
      relied on adapter frames machinery to ensure that the expected
      parameters are present on the stack, but on the same time the adapter
      frame tearing down code was effectively recovering the stack pointer
      potentially broken by the CSA builtin.
      
      Once we get rid of the arguments adapter frames keeping stack pointer
      in a valid state becomes crucial.
      
      Bug: v8:5269, v8:10201
      Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70454}
      5e5eaf79
    • Zhao Jiazhong's avatar
      [mips32] Implement V8_REVERSE_JSARGS · 94953266
      Zhao Jiazhong authored
      Bug: v8:10201
      Change-Id: I86cd6b73787cea307013dd311d048b20459ad573
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465052Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70447}
      94953266
  5. 09 Oct, 2020 2 commits
  6. 08 Oct, 2020 1 commit
  7. 07 Oct, 2020 3 commits
    • Ng Zhi An's avatar
      [x64] Refactor pinsrb family of instructions · e30c50f3
      Ng Zhi An authored
      The existing macro assembler define Pinsrb, which expects 3 arguments:
      
      - XMMRegister dst
      - Register/Operand src
      - uint8_t imm
      
      which overwrites dst with src at lane specified by imm.
      
      That means we cannot use the AVX version, which has 4 arguments, and
      does not overwrite dst.
      
      This refactoring defines the 4 argument AVX version instead, and if AVX
      is not supported, fall back to the SSE version, and ensure that the
      value is copied over into dst first.
      
      For convenience, we define an overload with 3 arguments that duplicates
      dst, this replicates the SSE behavior, so that not all callers have to
      be updated.
      
      Bug: v8:10975, v8:10933
      Change-Id: I6f9b9d37fa08d3f5cff4f040ae7d5e1f0cf36455
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444096
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70392}
      e30c50f3
    • Jakob Gruber's avatar
      [nci] Fix a DCHECK failure related to OSR · a19cf8e2
      Jakob Gruber authored
      This removes a DCHECK that is no longer valid now that NCI jobs can
      also be spawned by OSR requests.
      
      Bug: v8:8888
      Change-Id: I84eed41b510cc9c3ab1b35abfda0b6bec88752dd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2454714
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70373}
      a19cf8e2
    • Jakob Gruber's avatar
      [nci] Also spawn NCI tasks for OSR requests · ec76fb0f
      Jakob Gruber authored
      In addition to normal optimization requests, it also makes sense to
      consider OSR requests. In that case, the function is definitely hot,
      and since we've seen it OSR (i.e. we spend a long time inside a loop
      in the interpreted function), immediately jumping into NCI code in
      future contexts would be great.
      
      Future work: support OSR from NCI to TF.
      
      Bug: v8:8888
      Change-Id: Iaa4c60bc0c2e1bf3dc067053bb7b50e9af51c0d1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448462
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70364}
      ec76fb0f
  8. 06 Oct, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Add a --isolate-script-cache-ageing flag · af118269
      Jakob Gruber authored
      The NCI cache depends on the script cache (which is essentially a
      SharedFunctionInfo cache, and the SFIs contain bytecode) to
      deduplicate SFIs across native contexts. NCI caching does not work
      without script caching. Thus the lifetimes of both caches should
      match; in particular, disabling cache ageing for NCI is only effective
      if script cache ageing is also disabled.
      
      This CL adds an --isolate-script-cache-ageing flag. It's separate from
      the --turbo-nci-cache-ageing flag s.t. we can disable script cache
      ageing *without NCI* for benchmarking purposes.
      
      Future work: Good ageing heuristics for both script and nci caches.
      
      Bug: v8:8888
      Change-Id: Ia5546feeced5821a538d97db1bb8f5bb92528114
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2452471
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70339}
      af118269
  9. 05 Oct, 2020 2 commits
  10. 02 Oct, 2020 1 commit
  11. 01 Oct, 2020 1 commit
    • Dan Elphick's avatar
      [CSA] Tnodify CodeAssembler::Parameter · 74a9b9c4
      Dan Elphick authored
      CodeAssembler::Parameter now takes a Type template parameter and
      performs a checked cast to it. There is also UncheckedParameter which
      returns a TNode but doesn't check the cast. The original Parameter
      method is still there as UntypedParameter.
      
      Parameter<T>(x) in many cases replaces CAST(Parameter(x)), where the
      cast is performed inside Parameter. Since Parameter is not a macro,
      this means it cannot see the original expression or its file name and
      line number. So the error messages are vaguely useful, Parameter<T>()
      takes a SourceLocation parameter which with a default value of
      SourceLocation::Current(), which at least gives us the file name and
      line number for the error message.
      
      Bug: v8:6949, v8:10933
      Change-Id: I27157bec7dc7462210c1eb9c430c0180217d25c1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435106Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70264}
      74a9b9c4
  12. 30 Sep, 2020 4 commits
  13. 29 Sep, 2020 3 commits
  14. 28 Sep, 2020 5 commits
  15. 25 Sep, 2020 2 commits