Bug: chromium:1029530
Change-Id: I12aa4c238387f6a47bf149fd1a136ea83c385f4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962278
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65434}
Part of the GetObjectProperties test case is for verifying the human-
readable brief object description string that GetObjectProperties
returns. That string might look something like this:
"xy" (0x28f038d5 <v8::internal::SeqOneByteString>)
GetObjectProperties also tries to detect known immortal objects by
recognizing their addresses, which is useful in crash dumps with limited
memory. The recognized object name, if it exists, is prepended to the
description string. In order to provide this data accurately (in builds
without pointer compression), GetObjectProperties relies on the caller
to provide the addresses of the first pages in read-only space, map
space, and old space. If the caller doesn't provide those addresses,
then GetObjectProperties does the best it can with limited information
and reports possible matches based on an object's offset within the heap
page that contains it. So the result string might look like this, if the
object happened to get allocated at a lucky offset within its page:
maybe LoadHandler3Map "xy" (0x28f038d5 <v8::internal::SeqOneByteString>)
As a result, when testing these descriptions, we should generally check
that they contain the interesting data rather than that they start with
it, because some incorrect "maybe" match with a known object might be
included at the beginning.
Bug: v8:10034
Change-Id: I0cf5afd67793a239614aba3665ef57cd2d663a47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1950233
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65432}
With bytecode flushing and the current OSR triggering mechanism which
stores OSR nesting level on bytecode array it is possible to trigger
OSR on a closure that doesn't have feedback vector.
Bug: chromium:1031479
Change-Id: I4c62486f6b0eb6d6f9c96f98c1c1b275f3e6d6d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962850
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65431}
Factors out the group regexes from callstats.py so the two tools can
share them. When --group is specified, the stats are grouped together
using the callstats.py groupings. Also adds --filter (can be supplied
multiple times) to only show certain groups.
Under the hood, this converts the simple arrays and dictionaries to use
classes to simplify the code somewhat.
Change-Id: If6b548e109212adfdf46fa04e7b21638f84a0e26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962864
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65429}
This allows arbitrary expressions to specify the length of an array.
These expressions get access to globally declared things and the
preceding fields of the current object.
Unfortunately, this breaks generated C++ runtime code, so as a
workaround, I special-case expressions that are just an identifier
and handle them as before. We might want to support more cases there
in the future, probably also with special-casing since having a full
C++ back-end for Torque is infeasible.
Bug: v8:10004 v8:7793
Change-Id: I0d5d1200c0e727766beed7bfb2d43a8abb9cacf0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1942610
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65427}
operations.
Some 32-bit operations like kMips64And32, kMips64Or32 and kMips64Shr
overwrite the input registers' value by truncates the 64-bit value to
32 bits and sign-extends it,which may conflicts with later operatons
that need the input register's 64-bit value.
Change-Id: I29a5116999f7e851f38bdbcc5b066141a0617589
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928503
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#65426}
This cl: https://chromium-review.googlesource.com/c/v8/v8/+/1924439 has
renamed the optimize passed happening on the background to
OptimizeBackground instead of OptimizeConcurrent or RecompileConcurrent.
Concurrent optimization has main thread phases so using
OptimizeConcurrent for background computations only was a bit confusing.
Bug: chromium:1029456
Change-Id: I8f4a485831851d5a43ab87b3a5d74857559fd679
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1944157
Commit-Queue: Mythri Alle <mythria@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Auto-Submit: Mythri Alle <mythria@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65425}
This reverts commit fa62140475.
Reason for revert: Still breaks GPU bots like https://ci.chromium.org/p/v8/builders/ci/Linux%20V8%20FYI%20Release%20(NVIDIA)/7658
Original change's description:
> Reland "[turbofan][ptr-compr] Remove redundant ChangeTaggedToCompressed"
>
> This is a reland of c924f54ee0
>
> Will split the CL into parts since debugging is really hard for the
> combination of tests + bots that caused the failure.
>
> Relanding the safest part on this first CL.
>
> The difference between the original commit and this one can be seen in
> patchsets 1..2.
>
> Original change's description:
> > [turbofan][ptr-compr] Remove redundant ChangeTaggedToCompressed
> >
> > The final goal is to eliminate it altogether. This CL just
> > eliminate the redundant ones.
> >
> > Bug: v8:7703
> > Change-Id: If6e718c373fca7c65ce46c347533ec4550fbc444
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1950968
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#65398}
>
> Bug: v8:7703
> Change-Id: I5ff513a53eebcee6e2412f7ea8b801789476d50f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962277
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65423}
TBR=tebbi@chromium.org,solanes@chromium.org
Change-Id: I60bbf7061a733325e350d749c4adae65305b518c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7703
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962862
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65424}
This is a reland of c924f54ee0
Will split the CL into parts since debugging is really hard for the
combination of tests + bots that caused the failure.
Relanding the safest part on this first CL.
The difference between the original commit and this one can be seen in
patchsets 1..2.
Original change's description:
> [turbofan][ptr-compr] Remove redundant ChangeTaggedToCompressed
>
> The final goal is to eliminate it altogether. This CL just
> eliminate the redundant ones.
>
> Bug: v8:7703
> Change-Id: If6e718c373fca7c65ce46c347533ec4550fbc444
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1950968
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65398}
Bug: v8:7703
Change-Id: I5ff513a53eebcee6e2412f7ea8b801789476d50f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962277
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65423}
This unifies marking worklists handling by the main thread marker and
by the concurrent markers. A new class called MarkingWorklistsHolder
owns all marking worklists: the default worklist, the on-hold worklist,
and the embedder worklist. Each thread creates a local view of the
marking worklists by creating an instance of MarkingWorklists.
Additionally, marking visitors now work on MarkingWorklists instead of
accessing each worklist individually.
Besides cleaning the code up, this CL provides a bottleneck for
implementing per-context worklists.
Bug: chromium:973627
Change-Id: I52ad65c94bc0695287ba7bf4d8a814a9035e2888
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1941947
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65421}
In CodeStubAssembler::TryToIntptr(), code inside an Is64() block is
compiled on 32-bit, but |kMaxSafeIntegerUint64| cannot fit in an
intptr_t. To avoid this error, guard the Is64() block with
V8_TARGET_ARCH_64_BIT.
Change-Id: I5d82e4f649172e6054a767cc263a42bc02f89e58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960906
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65420}
TypedArrays cannot be handled on the JSArray path.
This patch should provide a minor performance improvement while
being functionally non-observable.
Change-Id: I05259517b9079aa715b3cf4be9b0cf6bb47236ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948712
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65419}
This reverts commit 3b7535636f.
Reason for revert: breaks in multiple places:
https://bugs.chromium.org/p/chromium/issues/detail?id=1029368https://bugs.chromium.org/p/chromium/issues/detail?id=1029361
Original change's description:
> Reland "[runtime] Cache prototype chain enumerable keys in PrototypeInfo"
>
> This is a reland of 5253d7bf15
>
> Original change's description:
> > [runtime] Cache prototype chain enumerable keys in PrototypeInfo
> >
> > This CL adds a prototype_chain_enum_cache to cache the enumeration of a
> > prototype and its entire chain on the PrototypeInfo. It can improve for-in
> > performance via simply merging the receiver enumeration with this cache.
> >
> > It improves the score of JetStream2-tagcloud-SP case by ~9% on IA Chromebook.
> >
> > Contributed by tao.pan@intel.com
> >
> > Change-Id: Ib40bfe41e772672337155584672f06fa1ba1e70d
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1870844
> > Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#65224}
>
> Change-Id: I93b74727c46abbaab163324c50fbd977fcc9bb36
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955232
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
> Cr-Commit-Position: refs/heads/master@{#65377}
TBR=verwaest@chromium.org,shiyu.zhang@intel.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I5b0d544e802ffda6a6804931087f37cb112805ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962273
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65418}
Found by combining dcheck_always_on with is_ubsan on x64.
Change-Id: Ie9bcf2402693aa3752be17421dd485533656df08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962271
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65417}
Found by MSVC. Cast the std::numeric_limits() result to size_t to make
the two sides of the comparison match.
Change-Id: Id480b973aad927315ae174003bf2e9ae182cd585
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960905
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65413}
This reverts commit 5f5b4b0407.
Reason for revert: Breaks vtunejit bot - see https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20vtunejit/32958
Original change's description:
> Support Intel VTune ITT API
>
> Add VTune domain support extension to use VTune Domain/Task API and
> tagging trace data for particular JS code block.
>
> How to use:
> 1. Set `"checkout_ittapi" = True` in the custom_vars section of .gclient
> file to download intel/ittapi by 'gclient sync'
> 2. Build d8 with gn build flag 'v8_enable_vtunetracemark = true'
> 3. Run d8 with flag '--enable-vtune-domain-support'
>
> The Vtune Domain/Task API can be invoked from JS to mark JS code block.
> You can mark the start of a JS task by
> vtunedomainmark(domain_name, task_name, "start")
> and the end of a task by
> vtunedomainmark(domain_name, task_name, "end")
> Tasks can nest.
>
> The VTune API (ittapi) is integrated as an external third party library
> while the v8_vtune_jit also relies on the VTune ittapi. We have another
> patch almost ready which refactors the v8_vtune_jit related code to
> depend on the third_party/ittapi. We will submit the refactored v8_vtune_jit
> code after this patch stabilized and landed.
>
>
> Contributed by fanchen.kong@intel.com
>
> Change-Id: I0ecc9dd4e1ea52545f1b6932fcdadfa7c1a6d2b2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938490
> Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65409}
TBR=machenbach@chromium.org,hpayer@chromium.org,verwaest@chromium.org,shiyu.zhang@intel.com
Change-Id: I44a6e5b1aa32e753ae41966ed321ed787cc752f8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960291
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65410}
Add VTune domain support extension to use VTune Domain/Task API and
tagging trace data for particular JS code block.
How to use:
1. Set `"checkout_ittapi" = True` in the custom_vars section of .gclient
file to download intel/ittapi by 'gclient sync'
2. Build d8 with gn build flag 'v8_enable_vtunetracemark = true'
3. Run d8 with flag '--enable-vtune-domain-support'
The Vtune Domain/Task API can be invoked from JS to mark JS code block.
You can mark the start of a JS task by
vtunedomainmark(domain_name, task_name, "start")
and the end of a task by
vtunedomainmark(domain_name, task_name, "end")
Tasks can nest.
The VTune API (ittapi) is integrated as an external third party library
while the v8_vtune_jit also relies on the VTune ittapi. We have another
patch almost ready which refactors the v8_vtune_jit related code to
depend on the third_party/ittapi. We will submit the refactored v8_vtune_jit
code after this patch stabilized and landed.
Contributed by fanchen.kong@intel.com
Change-Id: I0ecc9dd4e1ea52545f1b6932fcdadfa7c1a6d2b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938490
Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65409}
Add a method to set the URL of a Wasm script from a WasmStreaming object.
This will allow devtools to report the actual URL when it is available.
R=clemensb@chromium.org
Bug: v8:9762
Change-Id: Iccd41d76c9a4a2e1858716e8d555782404719faa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1944153
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65405}
- Move {function_} and {closure_hints_} out of each {Environment}, as
it's sufficient to only have it in the serializer class.
- Similarly, remove {parameter_count_} and {register_count_} from
{Environment}. To accomodate for that, change implementation of
"dead" environments to be based on a flag.
- Remove {ClearEphemeralHints}. This was called for any bytecode not
recognized by the serializer. I think it makes more sense to just
do nothing at all for those, i.e. keep whatever hints we have.
- Split the magical {ephemeral_hints_} vector into three separate
things for clarity: {accumulator_hints_}, {parameters_hints_}, and
{locals_hints}. Note that we already had {current_context_hints_}.
Bug: v8:7790
Change-Id: Icbe33f500bdbd0f8002570934f59425f49c9de12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1958010
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65400}
- Remove CLEAR_ENVIRONMENT_LIST of bytecodes, since clearing the
environment is already the default behavior.
- Address a TODO in Environment::Merge: also merge context hints.
- Don't needlessly clear register hints for InvokeIntrinsic.
Bug: v8:7790
Change-Id: Ibead921002e45ed46c8c1629cae7bb9febf09b90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1952870
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65399}
The final goal is to eliminate it altogether. This CL just
eliminate the redundant ones.
Bug: v8:7703
Change-Id: If6e718c373fca7c65ce46c347533ec4550fbc444
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1950968
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65398}
This CL generalizes and improves how we handle allocations in Torque.
Overview of the changes:
- Remove obsolete special handling for JSObject classes, since it was
incomplete: It breaks as soon as slack tracking is active.
- Handle array initialization using slices.
- Properly align allocation sizes. This enabled allocating strings.
- Port AllocateSeq{One,Two}ByteString to Torque, which is much easier
now than the old CSA code since allocation size alignment and
large-object space allocation just happen out-of-the-box.
- Remove obsolete or unnecessary intrinsics, some of them turn into
macros in the torque_internal namespace.
- Distinguish between header size and overall size for ClassType,
make size optional and only defined when it is statically known.
Bug: v8:10004 v8:7793
Change-Id: I623db233e7fb4deed54e8039ae0c24705e9a44e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1932356
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65397}
Add HeapObject overloads for MarkingBarrier, GenerationalBarrier and
WriteBarrierForCode, which the compiler automatically prefers if a
setter's type is a subclass of HeapObject. These overloads can skip
the IsHeapObject check, providing maybe a small performance boost and
I measure a ~4.5kB binary size reduction in libv8.so
Change-Id: Ia65ff8425ae4895da406587101c7813fe6bf5a2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1958055
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65395}
NOTE! This re-introduces the following change with a modification that
detached_window_time_in_seconds is initialized with 0, instead of
current time.
https://chromium-review.googlesource.com/c/v8/v8/+/1924000
Bug: chromium:1018156
Change-Id: I6d0880e0355d2cb08dbf4f2ef92c8fcead03f9ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1958344
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Bartek Nowierski <bartekn@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65393}
The API thread_cputime() is only defined but not yet implemented on IBMi.
Change-Id: I8ea7ff724e749f537b54e75a00d718500807ca8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1957831
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#65392}
We use the compilation entry point as a caching scope for deserializing
lookups, to avoid redundantly iterating over parent scopes when
accessing the same variable multiple times.
However, this caching scope messes with lookups that are looking for
lexical name conflicts, as opposed to just resolving variables. In
particular, it messes with name conflict lookups and sloppy block
function hoisting checks, when there are other scopes in the way, e.g.
function f() {
let x;
try {
throw 0;
}
catch (x) {
// This catch is the entry scope
// Naive use of caches will find the catch-bound x (which is
// a VAR), and declare 'no conflict'.
eval("var x;");
// Naive use of caches will find the catch-bound x (which is
// a VAR), and determine that this function can be hoisted.
eval("{ function x() {} }");
}
}
Previously, we worked around this by avoiding cache uses for these
lookups, but this had the issue of instead caching the same variable
multiple times, on different scopes. In particular, we saw:
function f() {
with ({}) {
// This with is the entry scope, any other scope would do
// though.
// The conflict check on `var f` caches the function name
// variable on the function scope, the subsequent 'real'
// lookup of `f` caches the function name variable on the
// entry i.e. with scope.
eval("var f; f;");
}
}
With this patch, we change the caching behaviour to cache on the first
non-eval declaration scope above the eval -- in the above examples, this
becomes the parent function "f". For compilations with no intermediate
non-decl scopes (no with or catch scopes between the function and eval)
this becomes equivalent to the existing entry-point-based caching.
This means that normal lookups do have to (sometimes) iterate more scopes,
and we do have to be careful when using the cache to not use it for
lookups in these intermediate scopes (a new IsOuterScope DCHECK guards
against this), but we can now safely ignore the cache scope when doing
the name-collision lookups, as they only iterate up to the outer
non-eval declaration scope anyway.
Bug: chromium:1026603
Bug: chromium:1029461
Change-Id: I9e7a96ce4b8adbc7ed47a49fba6fba58b526235b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955731
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65391}
This reverts commit 026a0c214a.
Reason for revert: Reverting due to https://crbug.com/1029461
Original change's description:
> [parser] Fix variable caching for conflict lookup
>
> During conflict lookup (for lexical variables and sloppy block function
> hoisting), we cache the looked-up variable on the current scope if the
> lookup goes through a ScopeInfo. However, for variable lookup during
> scope analysis, we use the "entry point" as the cache.
>
> Since both lookups can create Variables, this can cause us to create
> duplicate variables, e.g. a duplicate function name variable in the
> attached test.
>
> Instead, for ScopeInfo conflict lookups we can cache the result on the
> function's outer scope, which shoud be equivalent to the entry point.
>
> As a (necessary) drive-by, we can terminate the lookup early if we find
> a VAR with the same name, as we can safely assume that its existence
> means that it doesn't conflict, which means that our variable can't
> conflict either.
>
> Bug: chromium:1026603
> Change-Id: I19f80f65597ba6573ebe0b48aa5698f55e5c3ea1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928861
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65138}
TBR=leszeks@chromium.org,verwaest@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1026603
Bug: chromium:1029461
Change-Id: Id7f5dd342e32e1bb57c51b3748feff32ee0ba41d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1958014
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65390}
This reverts commit c4cf2ea4fd.
Reason for revert: Seems to cause more regressions than improvement. Let's see what the perf bots say about the revert.
Original change's description:
> [codegen] Remove redundant xorpd instructions
>
> It seems like they were originally added in https://crrev.com/23654026
> (Sep 2013) to break dependences in the OOO pipeline. This code pattern
> was then later copied for other instructions too
> (https://crrev.com/1424333002).
> The reason for the xorpd is not mentioned in the code though, and I
> found no other compiler doing this. So maybe it's obsolete by now, and
> only increases code size.
>
> Let's remove them and see if we get any performance regressions.
>
> R=ahaas@chromium.org
> CC=yangguo@chromium.org
>
> Change-Id: I0e6d65afa67f0ee286e5b0ba95c91092c5261c8f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926427
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65077}
TBR=yangguo@chromium.org,ahaas@chromium.org,clemensb@chromium.org
Bug: chromium:1027876, chromium:1027449
Change-Id: I533729722e294dbe567222b1c4084df6b864d2ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1958053
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65388}
Instead of using hard-coded clang flags (which are missing important
flags and are thus not that useful), use the flags for some unrelated
C++ file.
R=ahaas@chromium.org
No-Try: true
Change-Id: I516df9431e8aad1a63e832aa28450475193fd404
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955549
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65387}
