As part of that change, make ToNumber return in the accumulator.
Bug: v8:6791
Change-Id: I8ce0f4fbc7ad8ee7fb4a32a8a499394395010750
Reviewed-on: https://chromium-review.googlesource.com/658082
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47976}
Merge some stack operations to work on an even number of registers, adding
a padding register where necessary. Some lightly-used macro assembler
functions are inlined, to make pairing registers easier. Not all merges
create an even number of register arguments yet.
This is a step towards aligning the stack pointer to 16-bytes.
Bug: v8:6644
Change-Id: I995510cf91fa1f7af659a8d9b83acf7857787100
Reviewed-on: https://chromium-review.googlesource.com/654607
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47975}
During JSTypedLowering, when we see a JSAdd where we know that at least
one side is already a String, we can try to strength-reduce the other
side to a string as well. And once we have that, check whether both
sides are now String constants, and if the concatenation won't overflow
the string length limit, we can just constant-fold the StringAdd.
This improves the Six Speed template_string benchmarks by up to 5x, as
we no longer need to perform the String concatenations on every loop
iteration.
Bug: v8:6815
Change-Id: I8c47b2adf66b585d2f191cf805604b435f6256cd
Also-By: jarin@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/663181
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47974}
As per spec.
R=ahaas@chromium.org
Change-Id: I46d4bdd444452fef05c234688c27aad8d086bf61
Reviewed-on: https://chromium-review.googlesource.com/663457
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47973}
So far we didn't properly constant-fold JSToString operators in
JSTypedLowering where the input was a known number constant.
Bug: v8:6815
Change-Id: Iac87346b7d38f0f75461f285ea7daa2d5a5e1524
Reviewed-on: https://chromium-review.googlesource.com/663358
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47972}
Linux builds have an include chain from src/perf-jit.cc:
sys/mman.h -> bits/mman.h -> bits/mman-linux.h, which defines
a MAP_TYPE macro that conflicts with InstanceType::MAP_TYPE
in jumbo builds, for some jumbo_file_merge_limit values.
Since MAP_TYPE isn't used in perf-jit.cc, it should be safe
to #undef the macro immediately after the sys/mman.h #include
statement.
Bug: chromium:746958
Change-Id: I1339a4f56cf6783bf6121cd44c93e776af9458ba
Reviewed-on: https://chromium-review.googlesource.com/654042
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Cr-Commit-Position: refs/heads/master@{#47971}
This further reduces the amount of test-specific code. It will also
help testing the wasm baseline compiler, since it is also being called
from the {WasmCompilationUnit}.
Also, move the {RuntimeExceptionSupport} flag from the
{WasmFunctionCompiler} to the {TestingModuleBuilder}. There is no need
to store this per function builder. The {TestingModuleBuilder} then
passes it on to the {WasmCompilationUnit}, which finally sets it on the
{WasmGraphBuilder}.
R=mtrofin@chromium.org
Bug: v8:6600
Change-Id: I783dc296297a5ca37a2dd0d2035d782ca19a0fee
Reviewed-on: https://chromium-review.googlesource.com/660239
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47970}
We were using a boolean before, which makes the meaning non-obvious
when passed as a parameter. With the enum, you actually have to use
{kRuntimeExceptionSupport} or {kNoRuntimeExceptionSupport}.
R=mtrofin@chromium.org
Change-Id: Iaf5a7b6f1b446d4c3e16e044a6055d923d3b0b49
Reviewed-on: https://chromium-review.googlesource.com/660738
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47969}
Contributed by kanghua.yu@intel.com.
Bug: None
Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9
Reviewed-on: https://chromium-review.googlesource.com/604648
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Pan Deng <pan.deng@intel.com>
Cr-Commit-Position: refs/heads/master@{#47968}
Instead of four different constructors, we actually just need one. You
either pass a Counters*, or we will get it from the isolate (which is
only allowed to happen on the main thread).
This change makes refactoring this data structure for the baseline
compiler much easier.
R=mtrofin@chromium.orgCC=kschimpf@chromium.org
Bug: v8:6600
Change-Id: I56fb47005861dd4a203373776901930a02e09deb
Reviewed-on: https://chromium-review.googlesource.com/657979
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47964}
When accessing elements of a global (constant) JSArray, whose backing
store is copy-on-write, we can just constant-fold the value and insert
a check that the backing store stays the same.
Bug: v8:6816, v8:6815
Change-Id: I090bcec7b1ce72a1f9ed8625680ed91e8c67f27f
Reviewed-on: https://chromium-review.googlesource.com/662757
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47963}
- Memory.Grow with guard pages enabled should adjust amount of allocated
memory, and not allocate a new buffer. This was disabled because previously
the backing store was freed in the MemoryFinalizer, and we needed to be sure
that the backing store is not released till the last buffer using it is
released. This is now safe as we no longer use the MemoryFinalizer
- SetProtection should use Guard/Unprotect that use mprotect underneath,
instead of CommitRegion/UncommitRegion that use mmap
- Move buffer allocation to the end to avoid inconsistent memory due to GC
BUG=v8:5886
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I0d7edb884bd1e3167eb5fbced6953c6401688d40
Reviewed-on: https://chromium-review.googlesource.com/629517
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47960}
It causes a significant regression in TypedArray benchmarks. Thinking it
through, it is actually not necessary for the JavaScript memory model
either. I originally added it to ensure that reads/writes are not elided
or duplicated, but there is no guarantee of this behavior for non-atomic
writes in the model.
BUG=chromium:763814
R=clemensh@chromium.org
Change-Id: Ib03d2e2e77a846d4b9e84eebc7f8fbf861f8fd7c
Reviewed-on: https://chromium-review.googlesource.com/661192
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47957}
BigInt is a new primitive type of arbitrary precision integers,
proposed in https://tc39.github.io/proposal-bigint.
This CL introduces a corresponding instance type, map, and C++
class to V8 and adds BigInt support to a few operations (see the
test file). Much more is to come. Also, the concrete representation
of BigInts is not yet fixed, currently a BigInt is simply a wrapped
Smi.
Bug: v8:6791
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia2901948efd7808f17cfc945f0d56e23e8ae0b45
Reviewed-on: https://chromium-review.googlesource.com/657022
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47956}
This will introduce a new behavior on POSIX(-like) platforms. Timezone
names inside parentheses after GMT offset will not be 3-4 letter
abbreviation any longer. They'll be human-readable names in the current
default locale. This matches the current Windows behavior.
new Date(2017, 5, 22).toString()
new Date(2017, 11, 22).toString()
Current:
Thu Jun 22 2017 00:00:00 GMT-0700 (PDT)
Fri Dec 22 2017 00:00:00 GMT-0800 (PST)
New in en-US locale:
Thu Jun 22 2017 00:00:00 GMT-0700 (Pacific Daylight Time)
Fri Dec 22 2017 00:00:00 GMT-0800 (Pacific Standard Time)
New in German locale:
Thu Jun 22 2017 00:00:00 GMT-0700 (Nordamerikanische Westküsten-Sommerzeit)
Fri Dec 22 2017 00:00:00 GMT-0800 (Nordamerikanische Westküsten-Normalzeit)
BUG=v8:6031, v8:2137, v8:6076
TEST=mjsunit/icu-date-lord-howe.js, mjsunit/icu-date-to-string.js
Change-Id: I4e7fd8b3ddae5c7779e220c4c101e45904fcdc01
Reviewed-on: https://chromium-review.googlesource.com/625164
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47953}
This is a reland of da6aab4319
Original change's description:
> [snapshot] Temporarily enable --lazy-deserialization
>
> Flip the flag for one day to determine impact and flush out bugs.
> Please add crashes and regressions to https://crbug.com/v8/6796.
>
> Bug: v8:6624,v8:6796
> Change-Id: I8b0581c40d956e01f94e9098ff935fdd5af36156
> Reviewed-on: https://chromium-review.googlesource.com/651408
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Hablich <hablich@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47893}
Bug: v8:6624, v8:6796
Change-Id: I7df43925ccb2e6c1d3455439690526b0e1a6a747
Reviewed-on: https://chromium-review.googlesource.com/660218
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47952}
Since we don't have a full-codegen compiler anymore, we no longer
generate Code::FUNCTION kind. Nice! Here is some cleanup.
Bug: v8:6409
Change-Id: I05634e4ca85c4037b49a4346f4e8bae8042b8762
Reviewed-on: https://chromium-review.googlesource.com/657817
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47951}
The wasm code for asm.js modules is generated by us and does not come
from the user. Therefore we do not need to check in release builds that
experimental opcodes are not used for asm.js, a DCHECK is sufficient.
R=clemensh@chromium.org
Change-Id: I0c7135bfb03eafd2a39e648d57eff8e3a4440c3f
Reviewed-on: https://chromium-review.googlesource.com/659938
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47950}
We call this ~140 times from addReferences() and AddStubCache, which
caused size to increase.
Bug:
Change-Id: Ib08d435abb82b3e07121adf023f96f6f0b33733e
Reviewed-on: https://chromium-review.googlesource.com/660120
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47949}
This fixes two issues related to Code object allocation: Code objects
need to be aligned to kCodeAlignment (= 32), and the instruction cache
needs to be flushed after deserialization.
Both bugs combined manifested as a crash at a basically arbitrary point
in the code after the Runtime::kDeserializeLazy call:
0x286bc8dc: blx r12 // Call to Runtime::kDeserializeLazy,
// generated through
// GenerateTailCallToReturnedCode.
0x286bc8e0: mov r2, r0 // This seemingly innocent register move
// crashes hard.
Bug: v8:6624,v8:6796
Change-Id: I88c7eaf57ac851745fb7e800c92b0f5978b33466
Reviewed-on: https://chromium-review.googlesource.com/660119
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47947}
The wasm valiation incorrectly allowed simd locals, even without the
experimental flag turned on. This was not noted in the generated code
because simd opcodes were forbidden, but the interpreter could not
handle these locals.
R=clemensh@chromium.org
Bug: chromium:763697
Change-Id: I11d924ac21e50bce81d0504c2c7b252105a89f80
Reviewed-on: https://chromium-review.googlesource.com/660117
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47946}
With jumbo builds, we get spurious errors if several .cc files define
the same preprocessor macro without undefining it. This is also
disallowed by the style guide.
This patch adds a presubmit check to check that each #define is
eventually followed by a corresponding #undef. Special care has to be
taken for conditionally defined macros. Here, the logic to check that
there are not multiple defines and that they are undefined in all
cases is not perfect; it's optimistic in order to avoid false positives.
R=mstarzinger@chromium.org, machenbach@chromium.org
Bug: v8:6811
Change-Id: I55cde499399d97a5eb02fbc5ecfa34e6a8099d06
Reviewed-on: https://chromium-review.googlesource.com/657104
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47944}
The Typer put the wrong type on String#index and String#lastIndexOf
builtins, with an off by one on the upper bound.
Bug: chromium:762874
Change-Id: Ia4c29bc2e8e1c85b6a7ae0b99f8aaabf839a5932
Reviewed-on: https://chromium-review.googlesource.com/660000
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47942}
In the test case the module contained a memory which got exported by the
name 'main'. The fuzzer crashed when it tried to cast the memory to a
function to execute it. This CL checks that 'main' is a function before
doint the cast.
R=clemensh@chromium.org
Bug: chromium:763349
Change-Id: I9a21413c8038a7547f8b59057afea2870b15499a
Reviewed-on: https://chromium-review.googlesource.com/659978
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47941}
TurboFan wasn't able to inline calls to Array.prototype.push which
didn't have exactly one parameter. This was a rather artifical
limitation and was mostly due to the way the MaybeGrowFastElements
operator was implemented (which was not ideal by itself). Refactoring
this a bit, allows us to inline the operation in general, independent
of the number of values to push.
Array#push with multiple parameters is used quite a lot inside Ember (as
discovered by Apple, i.e. https://bugs.webkit.org/show_bug.cgi?id=175823)
and is also dominating the Six-Speed/SpreadLiterals/ES5 benchmark (see
https://twitter.com/SpiderMonkeyJS/status/906528938452832257 from the
SpiderMonkey folks). The micro-benchmark mentioned in the tracking bug
(v8:6808) improves from
arrayPush0: 2422 ms.
arrayPush1: 2567 ms.
arrayPush2: 4092 ms.
arrayPush3: 4308 ms.
to
arrayPush0: 798 ms.
arrayPush1: 2563 ms.
arrayPush2: 2623 ms.
arrayPush3: 2773 ms.
with this change, effectively removing the odd 50-60% performance
cliff that was associated with going from one parameter to two or
more.
Bug: v8:2229, v8:6808
Change-Id: Iffe4c1233903c04c3dc2062aad39d99769c8ab57
Reviewed-on: https://chromium-review.googlesource.com/657582
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47940}
If Coverage goes out of scope, ScriptData, FunctionData, or BlockData still rely on
Coverage's coverage_. Make coverage_ a shared_ptr owned by all four classes.
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ifab5d05184cc5db0fd0a935254b967286295e63f
Reviewed-on: https://chromium-review.googlesource.com/657381
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47938}
It's quite common today to use Function#apply together with typed
arrays, for example to construct a String from character codes (or code
points) within a Uint8Array or Uint16Array, i.e.
String.fromCharCode.apply(undefined, uint8array)
is seen quite often on the web. But there are other interesting cases
like
Math.max.apply(undefined, float64array)
to compute the maximum value in a Float64Array, which is definitely not
the fastest implementation, but quite convenient and readable.
Unfortunately these cases hit the super-slow-path of the Function#apply
machinery in V8 currently, because Function#apply doesn't have any
fast-path for TypedArrays.
This CL adds a proper fast-path to CreateListFromArrayLike to the
ElementsAccessor, which can be used as long as the typed array that's
passed wasn't neutered. With this fast-path in place, the performance on
the micro-benchmark mentioned in the issue improves from
stringFromCharCode: 6386 ms.
stringFromCodePoint: 8752 ms.
to
stringFromCharCode: 1932 ms.
stringFromCodePoint: 4262 ms.
which corresponds to a 2.0x-3.3x improvement.
Bug: v8:2435
Change-Id: I4d39666e53644b11d5856982b005928e26f296fe
Reviewed-on: https://chromium-review.googlesource.com/657405
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47936}
It is legal to stringify other kinds of values, like strings and numbers.
Since Local<Object> is convertible to Local<Value>, this is unlikely to
break callers.
Bug: v8:6810
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ie8e97c86308d62cdf0a2a17490a6e20de58fc76e
Reviewed-on: https://chromium-review.googlesource.com/657633
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47935}
Port 9e995e12ca
Port 408f252bfa
Up to now, each architecture defined all Register types as structs,
with lots of redundancy. An often found comment noted that they cannot
be classes due to initialization order problems. As these problems are
gone with C++11 constexpr constants, I now tried making Registers
classes again.
All register types now inherit from RegisterBase, which provides a
default set of methods and named constructors (like ::from_code,
code(), bit(), is_valid(), ...).
This design allows to guarantee an interesting property: Each register
is either valid, or it's the no_reg register. There are no other
invalid registers. This is guaranteed statically by the constexpr
constructor, and dynamically by ::from_code.
I decided to disallow the default constructor completely, so instead of
"Register reg;" you now need "Register reg = no_reg;". This makes
explicit how the Register is initialized.
I did this change to the x64, ia32, arm, arm64, mips and mips64 ports.
Overall, code got much more compact and more safe. In theory, it should
also increase performance (since the is_valid() check is simpler), but
this is probably not measurable.
R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I2e87efc8790290c64fd6c0a2d093326710b30ed3
Reviewed-on: https://chromium-review.googlesource.com/658065
Reviewed-by: Jaideep Bajwa <bjaideep@ca.ibm.com>
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#47933}
Even though we were generating additional arguments with default value
in the case that the caller was not providing enough, we then passed
the original pointer, leading to potential out-of-bounds accesses.
R=ahaas@chromium.org
Bug: chromium:763294,chromium:763297
Change-Id: Id18622d0d40e0408e26a5fc6f97494b5f9e18d17
Reviewed-on: https://chromium-review.googlesource.com/657699
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47930}
TSAN finds data races in generated JavaScript code that use
access the SharedArrayBuffer backing store racily. These are races, but
they are OK in the sense that the JavaScript memory model allows for the
potential bad behavior they could introduce (e.g. potentially tearing
reads). Relaxed atomics could be used here instead, but that could
introduce performance regressions.
This change adds TSAN annotations to the TypedArray reads/writes to
prevent TSAN from warning about them.
Bug: chromium:722871
Change-Id: I0776475f02a352b678ade7d32ed6bd4a6be98c36
Reviewed-on: https://chromium-review.googlesource.com/656509
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47929}
