We reset the profiler ticks when the feedback changes. So, we should
not update the feedback when the feedback hasn't changed. Added a
check in IC::ConfigureVectorState to see if the feedback has changed
before we update the feedback.
Bug:
Change-Id: I83f38656b52df7f687cd0c2eceac961dcd4f35f7
Reviewed-on: https://chromium-review.googlesource.com/657698
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47988}
* Inline src/runtime/runtime-typedarray.cc's TypedArrayCopyElements to
avoid clash with src/builtins/builtins-typedarray.cc
* #undef V after its last use in src/asmjs/asm-scanner.cc
* Convince clang that it's ok that frame_content_ is never used in
src/deoptimizer.h
Bug: chromium:746958
Change-Id: Ibef589b66384d982a8463c3f05b9db9c4fd92ce0
Reviewed-on: https://chromium-review.googlesource.com/663858
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Cr-Commit-Position: refs/heads/master@{#47986}
The Object.keys builtin didn't properly check for
empty_slow_elements_dictionary in addition to empty_fixed_array,
which made it miss the fast-path if you used it in combination with
like Object.freeze or Object.seal. This adds the missing fast-path
support.
Bug: v8:6767
Change-Id: I48e43b2ee51eb2d48446c45748401af096020bb7
Reviewed-on: https://chromium-review.googlesource.com/663539
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47985}
We assume that at this point the platform always exists. If this
assumption fails we have to reconsider how we call foreground tasks from
background tasks.
R=clemensh@chromium.org
Bug: chromium:764313
Change-Id: Ic2e61adc138cdf969f5b0bdf7702e839df5846b9
Reviewed-on: https://chromium-review.googlesource.com/663717
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47983}
Before we used to require compiled debugger script to report Scopes.
After migration inspection to brand-new native API we can report
Scopes all the time and remove this hidden dependency.
R=dgozman@chromium.org
Bug: none
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I3530bc7ead691a51073e384aea4a4ef428dc94da
Reviewed-on: https://chromium-review.googlesource.com/662097
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47982}
Some API functions have no context and debug::ScopeIterator::
CreateForFunction is crashing on attempt to get context.
R=jgruber@chromium.org
Bug: chromium:759913
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I0a9861ea2d19bceff97c4394b34a8dda45222b78
Reviewed-on: https://chromium-review.googlesource.com/661789
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47981}
This continues to move the "desugaring" of unary operators further
down the pipeline, in this case into the bytecode handlers for new
bytecodes `Negate` and `BitwiseNot` and the corresponding TF code
in BytecodeGraphBuilder.
Bug: v8:6971
Tbr: yangguo@chromium.org
Change-Id: If6b5d6b239a09ef8b4dbde49321614503c0f5beb
Reviewed-on: https://chromium-review.googlesource.com/661146
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47980}
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}