- 26 Jul, 2016 13 commits
-
-
machenbach authored
BUG=chromium:474921 Review-Url: https://codereview.chromium.org/2182933002 Cr-Commit-Position: refs/heads/master@{#38048}
-
ishell authored
BUG=chromium:625894 Review-Url: https://codereview.chromium.org/2181303002 Cr-Commit-Position: refs/heads/master@{#38047}
-
yangguo authored
This feature has not been used in the past few years and most likely does not even work anymore. R=ishell@chromium.org Review-Url: https://codereview.chromium.org/2186533002 Cr-Commit-Position: refs/heads/master@{#38046}
-
bgeron authored
BUG= R=danno Review-Url: https://codereview.chromium.org/2171543004 Cr-Commit-Position: refs/heads/master@{#38045}
-
machenbach authored
Revert of [interpreter] Add explicit OSR polling bytecode. (patchset #6 id:100001 of https://codereview.chromium.org/2172233002/ ) Reason for revert: Bunch of breakages. Maybe bad interaction with https://chromium.googlesource.com/v8/v8/+/e520e5da5550f0d1a975e87d6e66a2edecbb0c8e ? E.g.: https://build.chromium.org/p/client.v8/builders/V8%20Linux64/builds/11607 Original issue's description: > [interpreter] Add explicit OSR polling bytecode. > > This adds an explicit {OsrPoll} bytecode into every loop header which > triggers on-stack replacement when armed. Note that each such bytecode > stores the static loop depths as an operand, and hence can be armed for > specific loop depths. > > This also adds builtin code that triggers OSR compilation and switches > execution over to optimized code in case compilation succeeds. In case > compilation fails, the bytecode dispatch just continues unhindered. > > R=rmcilroy@chromium.org > TEST=mjsunit/ignition/osr-from-bytecode > BUG=v8:4764 > > Committed: https://crrev.com/a55beb68e0ededb3773affa294a71edc50621458 > Cr-Commit-Position: refs/heads/master@{#38043} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4764 Review-Url: https://codereview.chromium.org/2184553003 Cr-Commit-Position: refs/heads/master@{#38044}
-
mstarzinger authored
This adds an explicit {OsrPoll} bytecode into every loop header which triggers on-stack replacement when armed. Note that each such bytecode stores the static loop depths as an operand, and hence can be armed for specific loop depths. This also adds builtin code that triggers OSR compilation and switches execution over to optimized code in case compilation succeeds. In case compilation fails, the bytecode dispatch just continues unhindered. R=rmcilroy@chromium.org TEST=mjsunit/ignition/osr-from-bytecode BUG=v8:4764 Review-Url: https://codereview.chromium.org/2172233002 Cr-Commit-Position: refs/heads/master@{#38043}
-
yangguo authored
Doing so in a -pie build would make the snapshot non-deterministic. R=bmeurer@chromium.org BUG=v8:5233 Review-Url: https://codereview.chromium.org/2178093003 Cr-Commit-Position: refs/heads/master@{#38042}
-
machenbach authored
BUG=chromium:590036 NOTRY=true Review-Url: https://codereview.chromium.org/2185513002 Cr-Commit-Position: refs/heads/master@{#38041}
-
mstarzinger authored
This flag is aiming at shipping the ability to generate optimized code directly from bytecode (without re-parsing source code). All features needed to ship such a configuration will be staged behind this flag. R=hablich@chromium.org,rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2174333002 Cr-Commit-Position: refs/heads/master@{#38040}
-
ivica.bogosavljevic authored
Fix failure in mjsunit/wasm/embenchen/box2d on 32-bit architectures that do not support unaligned access. This test fails because WasmGraphBuilder::BuildCFuncInstruction allocates space for doubles using StackSlot turbofan operator, but this space is not guaranteed to be 8 bytes aligned if SP itself is not 8 bytes aligned (which is the case on 32-bit architectures). BUG=mjsunit/wasm/embenchen/box2d Review-Url: https://codereview.chromium.org/2177863002 Cr-Commit-Position: refs/heads/master@{#38039}
-
bmeurer authored
When we eliminate nodes during truncation analysis that have no value uses, we must make sure that we do not eliminate speculative number operations that would have side effects depending on the inputs, i.e. for example a SpeculativeNumberMultiply(x,y) does ToNumber(x) and ToNumber(y) first, so if either x or y could throw an exception during ToNumber conversion, we must not eliminate the multiplication, even if it has no value uses (some later pass may kill the actual machine multiplication, but the checks on the inputs have to remain still). So we check whether both x and y are PlainPrimitive, i.e. neither Receiver nor Symbol, which could raise exceptions for ToNumber, and only in that case we propagate the "unusedness" of the node to its inputs. This also uncovered a bug with the type of Dead, which must be None, as this represents an impossible value, so we had to fix that too. Also the dead code removal will not work correctly for constants (i.e. pure nodes with no value inputs), as those might be cached and hence we might resurrect them for an unrelated node lowering during SimplifiedLowering and only later kill the actual node (replacing its uses with Dead), which would then also replace the new use with Dead. So that was fixed as well. This shouldn't change anything for the result, as unused constants automagically disappear from the graph later on anyways. R=yangguo@chromium.org BUG=chromium:631318 Review-Url: https://codereview.chromium.org/2182003002 Cr-Commit-Position: refs/heads/master@{#38038}
-
benwells authored
Revert of MIPS: Fix '[turbofan] Prevent storing signalling NaNs into holey double arrays.' (patchset #2 id:20001 of https://codereview.chromium.org/2171303002/ ) Reason for revert: This bug has an error in the toolchain.gypi file, the conditions clause is repeated. This has broken the DrMemory builder - see first failing chromium build https://build.chromium.org/p/chromium.memory.fyi/builders/Chromium%20Windows%20Builder%20%28DrMemory%29/builds/17857 which included a v8 roll. For reference the errors are: gyp: Key 'conditions' repeated at level 11 with key path 'target_defaults.conditions.6.1.target_conditions.0.1.conditions.0.1' while reading C:\b\build\slave\drm-cr\build\src\v8\gypfiles\toolchain.gypi while reading includes of C:\b\build\slave\drm-cr\build\src\v8\src\d8.gyp gyp: Key 'conditions' repeated at level 11 with key path 'target_defaults.conditions.6.1.target_conditions.0.1.conditions.0.1' while reading C:\b\build\slave\drm-cr\build\src\v8\gypfiles\toolchain.gypi while reading includes of C:\b\build\slave\drm-cr\build\src\v8\src\v8.gyp gyp: Key 'conditions' repeated at level 11 with key path 'target_defaults.conditions.6.1.target_conditions.0.1.conditions.0.1' while reading C:\b\build\slave\drm-cr\build\src\v8\gypfiles\toolchain.gypi while reading includes of C:\b\build\slave\drm-cr\build\src\v8\samples\samples.gyp Original issue's description: > MIPS: Fix '[turbofan] Prevent storing signalling NaNs into holey double arrays.' > > Port 6470ddad > > On MIPS different signaling NaN values must be used for hardware and simulator targets, even at snapshot generation when always simulator is used. > > Original commit message: > This introduces SilenceNaN operator, which makes sure that we only > store quiet NaNs into holey arrays. We omit the NaN silencing code > at instruction selection time if the input is an operation that > cannot possibly produce signalling NaNs. > > BUG= > > Committed: https://crrev.com/52f2ceb052f63324050c7a098e4398f510b54763 > Cr-Commit-Position: refs/heads/master@{#38030} TBR=jarin@chromium.org,machenbach@google.com,akos.palfi@mattakis.com,ivica.bogosavljevic@imgtec.com,marija.antic@imgtec.com,ilija.pavlovic.imgtec@gmail.com,akos.palfi@imgtec.com,machenbach@chromium.org,balazs.kilvady@imgtec.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= TBR=machenbach Review-Url: https://codereview.chromium.org/2184573002 Cr-Commit-Position: refs/heads/master@{#38037}
-
v8-autoroll authored
Rolling v8/build to cce24bcaab6481f479f4baf00b5ea36d78268bcd Rolling v8/tools/mb to 11aa1bbe1b4fbae3694d14eb59b4eb98550bcbee TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review-Url: https://codereview.chromium.org/2181913002 Cr-Commit-Position: refs/heads/master@{#38036}
-
- 25 Jul, 2016 27 commits
-
-
bakkot authored
This slightly simplifies scope handling. It also makes it possible to implement some potential future changes to classes purely in the parser by adding additional code to the DoExpression. This is a portion of https://codereview.chromium.org/2142333002/, which probably isn't going through in full. Review-Url: https://codereview.chromium.org/2176653003 Cr-Commit-Position: refs/heads/master@{#38035}
-
yangguo authored
R=bmeurer@chromium.org BUG=v8:5197 Review-Url: https://codereview.chromium.org/2178943002 Cr-Commit-Position: refs/heads/master@{#38034}
-
machenbach authored
This prepares for switching arm64 sim to gn. BUG=chromium:474921 Review-Url: https://codereview.chromium.org/2174363002 Cr-Commit-Position: refs/heads/master@{#38033}
-
mlippautz authored
Reduces the dark matter of reported fixed arrays to < 5%. BUG=chromium:631094 R=ulan@chromium.org Review-Url: https://codereview.chromium.org/2181623002 Cr-Commit-Position: refs/heads/master@{#38032}
-
jarin authored
Review-Url: https://codereview.chromium.org/2174313002 Cr-Commit-Position: refs/heads/master@{#38031}
-
balazs.kilvady authored
Port 6470ddad On MIPS different signaling NaN values must be used for hardware and simulator targets, even at snapshot generation when always simulator is used. Original commit message: This introduces SilenceNaN operator, which makes sure that we only store quiet NaNs into holey arrays. We omit the NaN silencing code at instruction selection time if the input is an operation that cannot possibly produce signalling NaNs. BUG= Review-Url: https://codereview.chromium.org/2171303002 Cr-Commit-Position: refs/heads/master@{#38030}
-
bjaideep authored
On AIX clock_gettime provides CPU time with a resolution of 10ms, which causes the ThreadTicks testcase to fail since at the 2 instances the CPU time of the thread outputs to 0. Using AIX's API thread_cputime instead which provides CPU time with a resolution of 1ns. The testcase was added as part of https://codereview.chromium.org/1976603005 R=jochen@chromium.org, lpy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com BUG= LOG=N Review-Url: https://codereview.chromium.org/2174003002 Cr-Commit-Position: refs/heads/master@{#38029}
-
bjaideep authored
The testcase allocates JSArraybuffer on 2 separate pages which should be on the New space. In the testcase semi space size is set to 2MB. Since page size on PPC is 4MB the semi new space size defaults to 4MB. Therefore when allocating 2nd buffer, scavenge GC kicks in as from-space is filled up and copies 1st buffer to to-space. Now, the 2nd buffer also gets allocated on the same to-space, therefore both buffer end up being on the same page. This fix should allocate enough semi new space to contain 2 pages (for all platform). The testcase was added as part of https://codereview.chromium.org/2036643002 R=mlippautz@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com BUG= LOG=N Review-Url: https://codereview.chromium.org/2167853002 Cr-Commit-Position: refs/heads/master@{#38028}
-
bgeron authored
/ also selects the search box. BUG= Review-Url: https://codereview.chromium.org/2169053002 Cr-Commit-Position: refs/heads/master@{#38027}
-
caitp authored
The tests array-concat-revoked-proxy-*.js are copied out from array-concat.js, in order to verify that they work correctly with a valid ArrayProtector cell. These tests pass with https://crrev.com/122a9b7af02606dae558336082ab139a87eba39d applied, but fail without it. BUG=v8:5134 R=neis@chromium.org, cbruni@chromium.org, littledan@chromium.org Review-Url: https://codereview.chromium.org/2177903002 Cr-Commit-Position: refs/heads/master@{#38026}
-
bgeron authored
BUG= R=danno Review-Url: https://codereview.chromium.org/2169043002 Cr-Commit-Position: refs/heads/master@{#38025}
-
bgeron authored
If you dragged the node out of the bounding box, this commit allows you to see it again after you zoom. The zoom looks jittery, but I think it's better than not being able to see it at all. BUG= R=danno Review-Url: https://codereview.chromium.org/2168713005 Cr-Commit-Position: refs/heads/master@{#38024}
-
v8-autoroll authored
Rolling v8/build to bd9b7568ac244046c38f6c27d686d7661bfd4d27 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review-Url: https://codereview.chromium.org/2178803003 Cr-Commit-Position: refs/heads/master@{#38023}
-
ivica.bogosavljevic authored
Failure is due to different endianness on big endian. The test now passes on both big-endian and little-endian architectures. TEST=cctest/test-code-stubs-mips64/ConvertDToI BUG= Review-Url: https://codereview.chromium.org/2157373002 Cr-Commit-Position: refs/heads/master@{#38022}
-
tzik authored
For GYP build, V8 configures gtest and gmock in its //testing, and OTOH for GN build, it imports BUILD.gn from chromium and uses other configurations from its own. However, a recent chromium change on the BUILD.gn requires //testing update too. That prevents //build roll of V8. BUG=chromium:630299 Review-Url: https://codereview.chromium.org/2179743002 Cr-Commit-Position: refs/heads/master@{#38021}
-
neis authored
This flag has been enabled by default for over a month now. R=mstarzinger@chromium.org, rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2176143002 Cr-Commit-Position: refs/heads/master@{#38020}
-
klaasb authored
ToName was always generated with a subsequent Star, fuse them. Requires a few changes in the peephole optimizer as ToName cannot be elided as easily, but must be replaced by Star. BUG=v8:4280 LOG=n Review-Url: https://codereview.chromium.org/2169813002 Cr-Commit-Position: refs/heads/master@{#38019}
-
ishell authored
BUG=chromium:619166,chromium:625155 Review-Url: https://codereview.chromium.org/2175273002 Cr-Commit-Position: refs/heads/master@{#38018}
-
mstarzinger authored
This adds a new field to the header of every BytecodeArray which stores the current nesting level up to which loop back edges are armed as OSR points. The intention is to arm OSR points incrementally from outermost to innermost until one fires (similar to OSR from FullCodegen). R=rmcilroy@chromium.org BUG=v8:4764 Review-Url: https://codereview.chromium.org/2172583002 Cr-Commit-Position: refs/heads/master@{#38017}
-
mvstanton authored
After multiplying two integers we emit code like: if (result == 0) { if (OR_OPERATION(rhs, lhs) < 0) { DEOPT; } } This CL allows us to eliminate the OR and comparison if either rhs or lhs is a negative number, reducing the code to: if (result == 0) DEOPT; BUG= Review-Url: https://codereview.chromium.org/2167643002 Cr-Commit-Position: refs/heads/master@{#38016}
-
bmeurer authored
Turn the LoadElimination into a proper graph Reducer so that it can run together with ValueNumbering and RedundancyElimination to a fixpoint for maximum load/check elimination. This also adds initial support for eliminating redundant LoadElement/StoreElement nodes. BUG=v8:4930,v8:5141 Review-Url: https://codereview.chromium.org/2164253002 Cr-Commit-Position: refs/heads/master@{#38015}
-
mvstanton authored
BUG=chromium:630952 Review-Url: https://codereview.chromium.org/2177193002 Cr-Commit-Position: refs/heads/master@{#38014}
-
ivica.bogosavljevic authored
Fix failure in mjsunit/regress/regress-5213. When bailout happens, the double registers are not properly loaded if exponent_type() is INTEGER (this happens in optimized version of code only). BUG=mjsunit/regress/regress-5213 Review-Url: https://codereview.chromium.org/2175633003 Cr-Commit-Position: refs/heads/master@{#38013}
-
yangguo authored
BUG=v8:5197 Review-Url: https://codereview.chromium.org/2168273004 Cr-Commit-Position: refs/heads/master@{#38012}
-
machenbach authored
BUG=chromium:474921 Review-Url: https://codereview.chromium.org/2182443002 Cr-Commit-Position: refs/heads/master@{#38011}
-
rmcilroy authored
Move the logic for allocating the global declaration pair array from VisitDeclarations to a later step. This is required for concurrent bytecode generation. This change requires adding support for reserving fixed constant pool array entries, which can be later updated with the value of the literal. BUG=v8:5203 Review-Url: https://codereview.chromium.org/2167763003 Cr-Commit-Position: refs/heads/master@{#38010}
-
jochen authored
R=ishell@chromium.org,bmeurer@chromium.org TBR=rossberg@chromium.org BUG= Review-Url: https://codereview.chromium.org/2175233003 Cr-Commit-Position: refs/heads/master@{#38009}
-