Skip to content

V
V8
Switch branch/tag
  1. 02 Jul, 2015 1 commit
  3. 01 Jul, 2015 1 commit
    • danno's avatar
      Make context register implicit for CallInterfaceDescriptors · 7015fd20
      danno authored 
      Up until now the context register was listed explicitly in each stub's
CallInterfaceDescriptor. This was problematic, because it was listed
first in the list of register parameters--which is fine for Crankshaft,
which is more or less built to handle the context as the first
parameter-- but not ideal for TurboFan, which adds the context at
the end of all function parameters. Now the context register is no
longer in the register list and can be handled appropriately by both
compilers. Specifically, this allows the FunctionType specified for
each CallInterfaceDescriptor to exactly match the parameter register
list.

Review URL: https://codereview.chromium.org/1211333003

Cr-Commit-Position: refs/heads/master@{#29402}
      7015fd20
  5. 30 Jun, 2015 1 commit
  7. 25 Jun, 2015 1 commit
  9. 23 Jun, 2015 1 commit
  11. 19 Jun, 2015 1 commit
  13. 18 Jun, 2015 4 commits
  15. 08 Jun, 2015 1 commit
  17. 02 Jun, 2015 1 commit
  19. 01 Jun, 2015 1 commit
  21. 22 May, 2015 1 commit
  23. 20 May, 2015 1 commit
  25. 15 May, 2015 2 commits
  27. 12 May, 2015 1 commit
  29. 06 May, 2015 2 commits
  31. 05 May, 2015 4 commits
    • dslomov's avatar
      Handle the case when derived constructor is [[Call]]ed with 0 args. · cf53fed9
      dslomov authored 
      ArgumentsAdaptorStub for derived constructor (the one that needs
new.target) works in this way:
 - If the constructor is invoked via the Construct stub, we know that
   actual arguments always include new.target. ``arguments`` object
   however should not include a new.target, therefore we remove it.
   We achieve this by decrementing the argument count.
 - If the constructor is invoked as a call, we do not care for a correct
   ``arguments`` array since the constructor will immediately throw on
   entrance.
The bug is that the call could actually pass 0 actual arguments, but I
decrement unconditionally :(. The fix is to detect this case and avoid
decrementing. ``arguments`` is bogus, but it is ok as constructor
throws.

Long-term we should just remove mucking about with arguments for
new.target and just get it from the stack.

R=arv@chromium.org,rossberg@chromium.org
BUG=chromium:474783
LOG=Y

Review URL: https://codereview.chromium.org/1126783003

Cr-Commit-Position: refs/heads/master@{#28242}
      cf53fed9
    • danno's avatar
      Revert of Collect type feedback on result of Math.[round|ceil|floor] (patchset... · a988d5f2
      danno authored 
      Revert of Collect type feedback on result of Math.[round|ceil|floor] (patchset #13 id:230001 of https://codereview.chromium.org/1053143005/)

Reason for revert:
All sorts of performance regressions

Original issue's description:
> Collect type feedback on result of Math.[round|ceil|floor]
>
> By recording invocations of these builtins that can return -0, we now learn to not emit Crankshaft code that only handles integer results, avoiding deopt loops.
>
> Committed: https://crrev.com/f36ecaf3a4d61568ca50a20718acce7dd5da9a5f
> Cr-Commit-Position: refs/heads/master@{#28215}

TBR=mvstanton@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review URL: https://codereview.chromium.org/1115973005

Cr-Commit-Position: refs/heads/master@{#28237}
      a988d5f2
    • arv's avatar
      [es6] When comparing two symbols we may need to throw a TypeError · d26f5d39
      arv authored 
      When comparing a symbol to istself using <, <=, > or >= we need to
throw a TypeError. This is correctly handled in the runtime function
so if we are comparing a symbol fall back to use the runtime.

BUG=v8:4073
LOG=Y
R=rossberg@chromium.org

Review URL: https://codereview.chromium.org/1125783002

Cr-Commit-Position: refs/heads/master@{#28226}
      d26f5d39
    • danno's avatar
      Collect type feedback on result of Math.[round|ceil|floor] · f36ecaf3
      danno authored 
      By recording invocations of these builtins that can return -0, we now learn to not emit Crankshaft code that only handles integer results, avoiding deopt loops.

Review URL: https://codereview.chromium.org/1053143005

Cr-Commit-Position: refs/heads/master@{#28215}
      f36ecaf3
  33. 04 May, 2015 1 commit
  35. 10 Apr, 2015 1 commit
  37. 09 Apr, 2015 2 commits
  39. 07 Apr, 2015 2 commits
  41. 02 Apr, 2015 1 commit
  43. 31 Mar, 2015 1 commit
  45. 25 Mar, 2015 1 commit
    • mstarzinger's avatar
      Switch full-codegen from StackHandlers to handler table. · 38a719f9
      mstarzinger authored 
      This switches full-codegen to no longer push and pop StackHandler
markers onto the operand stack, but relies on a range-based handler
table instead. We only use StackHandlers in JSEntryStubs to mark the
transition from C to JS code.

Note that this makes deoptimization and OSR from within any try-block
work out of the box, makes the non-exception paths faster and should
overall be neutral on the memory footprint (pros).

On the other hand it makes the exception paths slower and actually
throwing and exception more expensive (cons).

R=yangguo@chromium.org
TEST=cctest/test-run-jsexceptions/DeoptTry

Review URL: https://codereview.chromium.org/1010883002

Cr-Commit-Position: refs/heads/master@{#27440}
      38a719f9
  47. 23 Mar, 2015 1 commit
    • mvstanton's avatar
      VectorICs: keyed element loads were kicking out non-smi keys unnecessarily · 6689cc27
      mvstanton authored 
      Handlers should be in charge of this work. The change uncovered a bug in
vector-ics related to keyed loads into strings. It's important for
StringCharCodeAtGenerator, a helper used in full code and in
LoadIndexedStringStub (a handler) to protect the vector and slot registers
when it makes a runtime call to convert a HeapNumber to a Smi.

It's still possible for the handler to MISS after this call, perhaps due
to out of bounds access. In that case, the vector and slot registers need
to be delivered safely to the MISS handler.

BUG=

Review URL: https://codereview.chromium.org/1028093002

Cr-Commit-Position: refs/heads/master@{#27377}
      6689cc27
  49. 17 Mar, 2015 2 commits
  51. 16 Mar, 2015 1 commit
  53. 06 Mar, 2015 1 commit
  55. 05 Mar, 2015 1 commit
  57. 03 Mar, 2015 1 commit