Skip to content

V
V8
Switch branch/tag
  1. 06 May, 2015 32 commits
  3. 05 May, 2015 8 commits
    • dpranke's avatar
      Adjust the visibility of the standalone targets in the GN build. · 978acb8d
      dpranke authored 
      As part of the migration from GYP->GN, we want to make sure that we
can track when new targets are added to either the GYP or GN builds
and that we are building everything we expect to build.

In GN, unlike GYP, if a build file gets referenced from other files,
building 'all' will cause every target to be built in it. This means in
particular, that we can end up trying to build targets that are not
necessarily intended to be visible to the rest of the build. To get
around this, any target that is defined but hidden (like 'v8_snapshot',
in V8's case) should still be visible to a top-level target called
"//:gn_visibility".

R=brettw@chromium.org, machenbach@chromium.org
BUG=461019
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#28243}
      978acb8d
    • 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
    • dusan.milosavljevic's avatar
      MIPS: Fix long branch mode and FPU branches. · c37f439b
      dusan.milosavljevic authored 
      - Add long branche mode for FPU branches.
- Fix FPU branches for unordered conditions.
- Provide FPU [un]ordered condition negation schema.

TEST=mjsunit/miror-objects, constant-folding-2, external-array
BUG=

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

Cr-Commit-Position: refs/heads/master@{#28241}
      c37f439b
    • balazs.kilvady's avatar
      MIPS: Improve '[es6] When comparing two symbols we may need to throw a TypeError'. · 2a86d26f
      balazs.kilvady authored 
      Improve d26f5d39

Original commit message:
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=

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

Cr-Commit-Position: refs/heads/master@{#28240}
      2a86d26f
    • mbrandy's avatar
      PPC: [turbofan] Fix tail call optimization. · 38f7ccba
      mbrandy authored 
      Port d21de2a4

Original commit message:
Tail calls are matched on the graph, with a dedicated tail call
optimization that is actually testable. The instruction selection can
still fall back to a regular if the platform constraints don't allow to
emit a tail call (i.e. the return locations of caller and callee differ
or the callee takes non-register parameters, which is a restriction that
will be removed in the future).

Also explicitly limit tail call optimization to stubs for now and drop
the global flag.

R=dstence@us.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

Cr-Commit-Position: refs/heads/master@{#28239}
      38f7ccba
    • wingo's avatar
      Revert of Resolve references to "this" the same way as normal variables... · 1e4173d9
      wingo authored 
      Revert of Resolve references to "this" the same way as normal variables (patchset #11 id:240001 of https://codereview.chromium.org/1097283003/)

Reason for revert:
nosnap failures

Original issue's description:
> Resolve references to "this" the same way as normal variables
>
> Make the parser handle references to "this" as unresolved variables, so the
> same logic as for the rest of function parameters is used for the receiver.
> Minor additions to the code generation handle copying the receiver to the
> context, along with the rest of the function parameters.
>
> Based on work by Adrian Perez de Castro <aperez@igalia.com>.
>
> BUG=
> LOG=N
>
> Committed: https://crrev.com/18619d355192e2699203d12d9ebb9caea107b693
> Cr-Commit-Position: refs/heads/master@{#28236}

TBR=rossberg@chromium.org,mstarzinger@chromium.org,dslomov@chromium.org,adamk@chromium.org,arv@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

Cr-Commit-Position: refs/heads/master@{#28238}
      1e4173d9
    • 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
    • wingo's avatar
      Resolve references to "this" the same way as normal variables · 18619d35
      wingo authored 
      Make the parser handle references to "this" as unresolved variables, so the
same logic as for the rest of function parameters is used for the receiver.
Minor additions to the code generation handle copying the receiver to the
context, along with the rest of the function parameters.

Based on work by Adrian Perez de Castro <aperez@igalia.com>.

BUG=
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#28236}
      18619d35