Skip to content

V
V8
Switch branch/tag
  1. 20 Dec, 2016 1 commit
  3. 16 Dec, 2016 1 commit
  5. 09 Dec, 2016 1 commit
  7. 01 Dec, 2016 1 commit
    • clemensh's avatar
      [base] Define CHECK comparison for signed vs. unsigned · db0c86fa
      clemensh authored 
      The current CHECK/DCHECK implementation fails statically if a signed
value is compared against an unsigned value. The common solution is to
cast on each caller, which is tedious and error-prone (might hide bugs).
This CL implements signed vs. unsigned comparisons by executing up to
two comparisons. For example, if i is int32_t and u is uint_32_t, a
DCHECK_LE(i, u) would create the check
i <= 0 || static_cast<uint32_t>(i) <= u.
For checks against constants, at least one of the checks can be removed
by compiler optimizations.

The tradeoff we have to make is to sometimes silently execute an
additional comparison. And we increase code complexity of course, even
though the usage is just as easy (or even easier) as before.

The compile time impact seems to be minimal:
I ran 3 full compilations for Optdebug on my local machine, one time on
the current ToT, one time with this CL plus http://crrev.com/2524093002.
Before: 143.72 +- 1.21 seconds
Now: 144.18 +- 0.67 seconds

In order to check that the new comparisons are working, I refactored
some DCHECKs in wasm to use the new magic, and added unit test cases.

R=ishell@chromium.org, titzer@chromium.org
CC=ahaas@chromium.org, bmeurer@chromium.org

Committed: https://crrev.com/5925074a9dab5a8577766545b91b62f2c531d3dc
Review-Url: https://codereview.chromium.org/2526783002
Cr-Original-Commit-Position: refs/heads/master@{#41275}
Cr-Commit-Position: refs/heads/master@{#41411}
      db0c86fa
  9. 29 Nov, 2016 1 commit
  11. 24 Nov, 2016 5 commits
    • clemensh's avatar
      Revert of [base] Pass scalar arguments by value in CHECK/DCHECK (patchset #3... · 29ee6244
      clemensh authored 
      Revert of [base] Pass scalar arguments by value in CHECK/DCHECK (patchset #3 id:40001 of https://codereview.chromium.org/2524093002/ )

Reason for revert:
Seems to cause compile errors on Android. Will investigate on Monday.

Original issue's description:
> [base] Pass scalar arguments by value in CHECK/DCHECK
>
> This not only potentially improves performance, but also avoids weird
> linker errors, like the one below, where I used Smi::kMinValue in a
> DCHECK_EQ.
>
> > [421/649] LINK ./mksnapshot
> > FAILED: mksnapshot
> > src/base/logging.h|178| error: undefined reference to
>   'v8::internal::Smi::kMinValue'
>
> R=bmeurer@chromium.org, ishell@chromium.org
>
> Committed: https://crrev.com/76723502528c5af003fdffc3520632ea2a13fef3
> Cr-Commit-Position: refs/heads/master@{#41273}

TBR=bmeurer@chromium.org,ishell@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review-Url: https://codereview.chromium.org/2527883004
Cr-Commit-Position: refs/heads/master@{#41278}
      29ee6244
    • clemensh's avatar
      Revert of [base] Define CHECK comparison for signed vs. unsigned (patchset #5... · 0406620c
      clemensh authored 
      Revert of [base] Define CHECK comparison for signed vs. unsigned (patchset #5 id:80001 of https://codereview.chromium.org/2526783002/ )

Reason for revert:
Need to revert previous CL because of Android compile error, and this one depends in it.

Original issue's description:
> [base] Define CHECK comparison for signed vs. unsigned
>
> The current CHECK/DCHECK implementation fails statically if a signed
> value is compared against an unsigned value. The common solution is to
> cast on each caller, which is tedious and error-prone (might hide bugs).
> This CL implements signed vs. unsigned comparisons by executing up to
> two comparisons. For example, if i is int32_t and u is uint_32_t, a
> DCHECK_LE(i, u) would create the check
> i <= 0 || static_cast<uint32_t>(i) <= u.
> For checks against constants, at least one of the checks can be removed
> by compiler optimizations.
>
> The tradeoff we have to make is to sometimes silently execute an
> additional comparison. And we increase code complexity of course, even
> though the usage is just as easy (or even easier) as before.
>
> The compile time impact seems to be minimal:
> I ran 3 full compilations for Optdebug on my local machine, one time on
> the current ToT, one time with this CL plus http://crrev.com/2524093002.
> Before: 143.72 +- 1.21 seconds
> Now: 144.18 +- 0.67 seconds
>
> In order to check that the new comparisons are working, I refactored
> some DCHECKs in wasm to use the new magic.
>
> R=bmeurer@chromium.org, titzer@chromium.org
>
> Committed: https://crrev.com/5925074a9dab5a8577766545b91b62f2c531d3dc
> Cr-Commit-Position: refs/heads/master@{#41275}

TBR=ishell@chromium.org,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review-Url: https://codereview.chromium.org/2531533003
Cr-Commit-Position: refs/heads/master@{#41277}
      0406620c
    • clemensh's avatar
      [base] Define CHECK comparison for signed vs. unsigned · 5925074a
      clemensh authored 
      The current CHECK/DCHECK implementation fails statically if a signed
value is compared against an unsigned value. The common solution is to
cast on each caller, which is tedious and error-prone (might hide bugs).
This CL implements signed vs. unsigned comparisons by executing up to
two comparisons. For example, if i is int32_t and u is uint_32_t, a
DCHECK_LE(i, u) would create the check
i <= 0 || static_cast<uint32_t>(i) <= u.
For checks against constants, at least one of the checks can be removed
by compiler optimizations.

The tradeoff we have to make is to sometimes silently execute an
additional comparison. And we increase code complexity of course, even
though the usage is just as easy (or even easier) as before.

The compile time impact seems to be minimal:
I ran 3 full compilations for Optdebug on my local machine, one time on
the current ToT, one time with this CL plus http://crrev.com/2524093002.
Before: 143.72 +- 1.21 seconds
Now: 144.18 +- 0.67 seconds

In order to check that the new comparisons are working, I refactored
some DCHECKs in wasm to use the new magic.

R=bmeurer@chromium.org, titzer@chromium.org

Review-Url: https://codereview.chromium.org/2526783002
Cr-Commit-Position: refs/heads/master@{#41275}
      5925074a
    • clemensh's avatar
      [base] Pass scalar arguments by value in CHECK/DCHECK · 76723502
      clemensh authored 
      This not only potentially improves performance, but also avoids weird
linker errors, like the one below, where I used Smi::kMinValue in a
DCHECK_EQ.

> [421/649] LINK ./mksnapshot
> FAILED: mksnapshot
> src/base/logging.h|178| error: undefined reference to
  'v8::internal::Smi::kMinValue'

R=bmeurer@chromium.org, ishell@chromium.org

Review-Url: https://codereview.chromium.org/2524093002
Cr-Commit-Position: refs/heads/master@{#41273}
      76723502
    • verwaest's avatar
      Fix zone in which temp-zone parsed data is allocated for the function scope on the boundary. · c4ccbaa3
      verwaest authored 
      BUG=chromium:417697

Review-Url: https://codereview.chromium.org/2522223002
Cr-Commit-Position: refs/heads/master@{#41271}
      c4ccbaa3
  13. 23 Nov, 2016 1 commit
  15. 21 Nov, 2016 2 commits
    • cbruni's avatar
      Revert of [counters] RuntimeStats: fix wrong bookkeeping when dynamically... · 10a31136
      cbruni authored 
      Revert of [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters. (patchset #10 id:180001 of https://codereview.chromium.org/2511093002/ )

Reason for revert:
Wronged it even more.

Original issue's description:
> [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters
>
> RuntimeTimerScopes always subtract their own time from the parent timer's
> counter to properly account for the own time. Once a scope is destructed it
> adds it own timer to the current active counter. However, if the current
> counter is changed with CorrectCurrentCounterId we will attribute all the
> subtimers to the previous counter, and add the own time to the new counter.
> This way it is possible to end up with negative times in certain counters but
> the overall would still be correct.
>
> BUG=
>
> Committed: https://crrev.com/f6c74d964d9387df4bed3d8c1ded51eb9e8aa6e8
> Cr-Commit-Position: refs/heads/master@{#41142}

TBR=ishell@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Review-Url: https://codereview.chromium.org/2519073002
Cr-Commit-Position: refs/heads/master@{#41150}
      10a31136
    • cbruni's avatar
      [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters · f6c74d96
      cbruni authored 
      RuntimeTimerScopes always subtract their own time from the parent timer's
counter to properly account for the own time. Once a scope is destructed it
adds it own timer to the current active counter. However, if the current
counter is changed with CorrectCurrentCounterId we will attribute all the
subtimers to the previous counter, and add the own time to the new counter.
This way it is possible to end up with negative times in certain counters but
the overall would still be correct.

BUG=

Review-Url: https://codereview.chromium.org/2511093002
Cr-Commit-Position: refs/heads/master@{#41142}
      f6c74d96
  17. 17 Nov, 2016 1 commit
  19. 14 Nov, 2016 1 commit
  21. 11 Nov, 2016 2 commits
  23. 10 Nov, 2016 1 commit
  25. 21 Oct, 2016 3 commits
  27. 19 Oct, 2016 1 commit
  29. 18 Oct, 2016 1 commit
  31. 14 Oct, 2016 1 commit
  33. 12 Oct, 2016 1 commit
  35. 10 Oct, 2016 1 commit
  37. 07 Oct, 2016 1 commit
  39. 05 Oct, 2016 2 commits
    • adamk's avatar
      Revert of Reland "Turn libbase into a component" (patchset #1 id:1 of... · e75b9f6e
      adamk authored 
      Revert of Reland "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2395553002/ )

Reason for revert:
Speculative revert due to very strange-looking win/dbg failures
which reference SignedDivisionByConstant:

https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/12736

Original issue's description:
> Reland "Turn libbase into a component"
>
> Original issue's description:
> > Turn libbase into a component
> >
> > This is a precondition for turning libplatform into a component
> >
> > BUG=v8:5412
> > R=jgruber@chromium.org,machenbach@chromium.org
> > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_
> dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe
> >
> > Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104
> > Cr-Commit-Position: refs/heads/master@{#39950}
>
> BUG=v8:5412
> TBR=jgruber@chromium.org,machenbach@chromium.org
> CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng
>
> Committed: https://crrev.com/17cb51254cafa932025e9980b60f89f756d411cb
> Cr-Commit-Position: refs/heads/master@{#39969}

TBR=jgruber@chromium.org,machenbach@chromium.org,jochen@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5412

Review-Url: https://codereview.chromium.org/2396933002
Cr-Commit-Position: refs/heads/master@{#40009}
      e75b9f6e
    • jochen's avatar
      Reland "Turn libbase into a component" · 17cb5125
      jochen authored 
      Original issue's description:
> Turn libbase into a component
>
> This is a precondition for turning libplatform into a component
>
> BUG=v8:5412
> R=jgruber@chromium.org,machenbach@chromium.org
> CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_
dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe
>
> Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104
> Cr-Commit-Position: refs/heads/master@{#39950}

BUG=v8:5412
TBR=jgruber@chromium.org,machenbach@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng

Review-Url: https://codereview.chromium.org/2395553002
Cr-Commit-Position: refs/heads/master@{#39969}
      17cb5125
  41. 04 Oct, 2016 3 commits
  43. 03 Oct, 2016 1 commit
    • leszeks's avatar
      [base] Optimise hashmaps with simple key equality · 306f8311
      leszeks authored 
      Hashmaps with a simple key equality method (comparing pointers) don't
need to waste cycles (and branches) comparing hash values, as the key
comparison is cheap.

This patch modifies the hashmap's MatchFun to take the hashes as well as
the keys, thus allowing the MatchFun to ignore the hashes. This allows
slightly cleaner generated code, especially when the MatchFun is
inlined.

BUG=

Review-Url: https://codereview.chromium.org/2381303002
Cr-Commit-Position: refs/heads/master@{#39932}
      306f8311
  45. 30 Sep, 2016 1 commit
  47. 29 Sep, 2016 2 commits
    • leszeks's avatar
      [interpreter] Use hashmap for ConstantArrayBuilder's constant map · 0134ddae
      leszeks authored 
      Uses the base hashmap to store the ConstantArrayBuilder's constant map,
which slightly improves the performance of ConstantArrayBuilder::Insert.

Includes a small overload of the hashmap LookupOrInsert method, which
allows passing in a value creation function instead of just default
initialising new values.

On Octane's codeload, this gives (on my machine) a 0.27% improvement,
which doesn't sound like a lot but I guess every little helps.

Review-Url: https://codereview.chromium.org/2336553002
Cr-Commit-Position: refs/heads/master@{#39883}
      0134ddae
    • leszeks's avatar
      [base] Template MatchFun in TemplateHashMapImpl · 837c91e8
      leszeks authored 
      Make MatchFun a template parameter in TemplateHashMapImpl, moving the
PointersMatch function down to an implementation which extends
TemplateHashMapImpl to void* key and value (i.e. the same as the current
HashMap and ZoneHashMap typedefs).

This will allow other instantiations of TemplateHashMapImpl, with
different MatchFun values, e.g. std::equal_to, to have their key
equality test inlined, rather than calling a function pointer,

Review-Url: https://codereview.chromium.org/2354593002
Cr-Commit-Position: refs/heads/master@{#39868}
      837c91e8
  49. 23 Sep, 2016 2 commits
  51. 22 Sep, 2016 1 commit
  53. 20 Sep, 2016 1 commit