- 21 Apr, 2016 3 commits
-
-
jyan authored
Port 3518e492 Original commit message: Short external strings do not cache the resource data, and may be used for compressible strings. The assumptions about their lengths is invalid and may lead to oob reads. R=yangguo@chromium.org, joransiu@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com BUG=v8:4923,chromium:604897 LOG=N Review URL: https://codereview.chromium.org/1911633002 Cr-Commit-Position: refs/heads/master@{#35682}
-
zhengxing.li authored
port 3518e492 (r35660) original commit message: Short external strings do not cache the resource data, and may be used for compressible strings. The assumptions about their lengths is invalid and may lead to oob reads. BUG= Review URL: https://codereview.chromium.org/1904003003 Cr-Commit-Position: refs/heads/master@{#35681}
-
bradnelson authored
BUG= https://code.google.com/p/v8/issues/detail?id=4203 BUG= https://bugs.chromium.org/p/chromium/issues/detail?id=575167 TEST=None R=ahaas@chromium.org,isherman@chromium.org LOG=N Review URL: https://codereview.chromium.org/1895223004 Cr-Commit-Position: refs/heads/master@{#35680}
-
- 20 Apr, 2016 37 commits
-
-
rmcilroy authored
BUG=v8:4681 LOG=N Review URL: https://codereview.chromium.org/1894073007 Cr-Commit-Position: refs/heads/master@{#35679}
-
adamk authored
Our previous over-conservative answer caused us to emit hole checks in full-codegen when eagerly parsing but not when lazily parsing. With this patch, we use the positions of the BinaryOperations making up the parameter list (which are the positions of the commas) to determine the appropriate "end position" for each parameter's initializer. This means that we get accurate-enough positions for the initializers in the eager parsing step to get the same answers for hole-check-elimination that we will later during ParseLazy. In the included test case, for example: (function() { ((s = 17, y = s) => s)(); } )(); ^2 ^1 The old code would generate a hole check when trying to load |s| for assignment to |y| (because it treated the closing parentheses pointed to by "^1" as the "initialization position" of |s|). The new code uses the comma pointed to by "^2" as the initialization position of |s|. Since that occurs textually before the load of |s|, full-codegen knows it can avoid the hole check. BUG=v8:4908 LOG=n Review URL: https://codereview.chromium.org/1900343002 Cr-Commit-Position: refs/heads/master@{#35678}
-
jyan authored
Port 81a1530e Original commit message: Before frame elision, we finalized the frame shape when assembling the prologue, which is also when we prepared the frame (saving sp, etc). The frame finalization only needs to happen once, and happens to be actually a set of idempotent operations. With frame elision, the logic for frame finalization was happening every time we constructed the frame. Albeit idempotent operations, the code would become hard to maintain. This change separates frame shape finalization from frame construction. When constructing the CodeGenerator, we finalize the frame. Subsequent access is to a const Frame*. Also renamed AssemblePrologue to AssembleConstructFrame, as suggested in the frame elision CR. Separating frame setup gave the opportunity to do away with architecture-independent frame aligning (which is something just arm64 cares about), and also with stack pointer setup (also arm64). Both of these happen now at frame finalization on arm64. R=mtrofin@chromium.org, joransiu@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com BUG= LOG=N Review URL: https://codereview.chromium.org/1903403002 Cr-Commit-Position: refs/heads/master@{#35677}
-
littledan authored
New incoming test262 tests check what happens on detached ("neutered") ArrayBuffers. This patch makes the test262 infrastructure define detaching an ArrayBuffer in terms of %ArrayBufferNeuter, passing the --allow-natives-syntax flag, when it is needed. BUG=v8:4193 LOG=N R=adamk,machenbach Review URL: https://codereview.chromium.org/1897203003 Cr-Commit-Position: refs/heads/master@{#35676}
-
bryleun authored
R=joransiu@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com,jyan@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1905613002 Cr-Commit-Position: refs/heads/master@{#35675}
-
bjaideep authored
Port 81a1530e Original commit message: Before frame elision, we finalized the frame shape when assembling the prologue, which is also when we prepared the frame (saving sp, etc). The frame finalization only needs to happen once, and happens to be actually a set of idempotent operations. With frame elision, the logic for frame finalization was happening every time we constructed the frame. Albeit idempotent operations, the code would become hard to maintain. This change separates frame shape finalization from frame construction. When constructing the CodeGenerator, we finalize the frame. Subsequent access is to a const Frame*. Also renamed AssemblePrologue to AssembleConstructFrame, as suggested in the frame elision CR. Separating frame setup gave the opportunity to do away with architecture-independent frame aligning (which is something just arm64 cares about), and also with stack pointer setup (also arm64). Both of these happen now at frame finalization on arm64. R=mtrofin@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/1903343002 Cr-Commit-Position: refs/heads/master@{#35674}
-
jyan authored
Port 59546149 Original commit message: Now that all 'const' declarations are of the ES2015 variety, the only use of CONST_LEGACY is for function name bindings in sloppy mode named function expressions. This patch aims to delete all code meant to handle other cases, which mostly had to do with hole initialization/hole checks. Since function name bindings are initialized at entry to a function, it's impossible to ever observe one in an uninitialized state. To simplify the patch further, it removes the `IMPORT` VariableMode, as it's not likely to be needed (IMPORT is identical to CONST for the purpose of VariableMode). R=adamk@chromium.org, joransiu@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com BUG= LOG=N Review URL: https://codereview.chromium.org/1901423004 Cr-Commit-Position: refs/heads/master@{#35673}
-
jyan authored
Port 623ad7de Original commit message: Removes the register file machine register from the interpreter and replaces it will loads from the parent frame pointer. As part of this change the raw operand values for register values changes to enable the interpreter to keep using the operand value as the offset from the parent frame pointer. R=rmcilroy@chromium.org, joransiu@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1910503002 Cr-Commit-Position: refs/heads/master@{#35672}
-
bjaideep authored
Port 3518e492 Original commit message: Short external strings do not cache the resource data, and may be used for compressible strings. The assumptions about their lengths is invalid and may lead to oob reads. R=yangguo@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com BUG=v8:4923,chromium:604897 LOG=N Review URL: https://codereview.chromium.org/1901593005 Cr-Commit-Position: refs/heads/master@{#35671}
-
machenbach authored
Revert of [wasm] Also test structured stack trace (patchset #4 id:60001 of https://codereview.chromium.org/1875153002/ ) Reason for revert: Breaks: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20custom%20snapshot%20-%20debug/builds/6322 Original issue's description: > [wasm] Also test structured stack trace > > This extends the wasm test case which only checks the "simple" > string-variant of the stack trace. > It checks the return values of the getFunctionName, getLineNumber, > getFileName and toString methods. > > R=ahaas@chromium.org, jfb@chromium.org, titzer@chromium.org > BUG= TBR=ahaas@chromium.org,jfb@chromium.org,titzer@chromium.org,clemensh@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1903293002 Cr-Commit-Position: refs/heads/master@{#35670}
-
clemensh authored
Fix tomorrow. BUG= TBR=mstarzinger@chromium.org,machenbach@chromium.org NOTRY=true NOTREECHECKS=true Review URL: https://codereview.chromium.org/1910493002 Cr-Commit-Position: refs/heads/master@{#35669}
-
rmcilroy authored
BUG=v8:4928 LOG=N TBR=machenbach@chromium.org NOTRY=true Review URL: https://codereview.chromium.org/1902263007 Cr-Commit-Position: refs/heads/master@{#35668}
-
littledan authored
This causes an incoming test262 test to pass, as part of the next test262 roll. R=adamk,machenbach BUG=v8:1569 LOG=N Review URL: https://codereview.chromium.org/1896293003 Cr-Commit-Position: refs/heads/master@{#35667}
-
clemensh authored
This extends the wasm test case which only checks the "simple" string-variant of the stack trace. It checks the return values of the getFunctionName, getLineNumber, getFileName and toString methods. R=ahaas@chromium.org, jfb@chromium.org, titzer@chromium.org BUG= Review URL: https://codereview.chromium.org/1875153002 Cr-Commit-Position: refs/heads/master@{#35666}
-
clemensh authored
In contrast to the existing cctest, this time the error is not thrown from javascript, but by a trap in wasm. And in contrast to the mjsunit tests, this checks the detailed stack trace, not the simple one. R=jfb@chromium.org, mstarzinger@chromium.org, titzer@chromium.org BUG= Review URL: https://codereview.chromium.org/1884593002 Cr-Commit-Position: refs/heads/master@{#35665}
-
clemensh authored
Before, just a string was thrown, so no stack trace was attached there. Generated code from wasm does not grow by this change, we just pass a message id to the respective (new) runtime function. R=mstarzinger@chromium.org, titzer@chromium.org BUG= Review URL: https://codereview.chromium.org/1874383002 Cr-Commit-Position: refs/heads/master@{#35664}
-
ahaas authored
All wasm spec tests can now be run on ia32. R=titzer@chromium.org Review URL: https://codereview.chromium.org/1899753004 Cr-Commit-Position: refs/heads/master@{#35663}
-
thakis authored
clang assumes 16-byte stack alignment, but incoming stack alignment isn't always guaranteed to be that way. It looks like v8 was lucky to not hit this so far. See https://crbug.com/418554 -- this makes v8's standalone config match Chromium. See also https://llvm.org/bugs/show_bug.cgi?id=21414 Maybe it's possible to change the caller of OnEntryHook() to guarantee the right alignment, but matching Chromium's build flags here seems like a good idea in general. BUG=v8:4928 LOG=n Committed: https://crrev.com/3afb3324941625559635380ef98a2ee73e370a0a Cr-Commit-Position: refs/heads/master@{#35597} Review URL: https://codereview.chromium.org/1899783002 Cr-Commit-Position: refs/heads/master@{#35662}
-
mstarzinger authored
This is just a pure renaming because "baseline" will be the code name for our upcoming middle tier within the compilation pipeline. It makes sure the name "baseline" remains unused. R=rmcilroy@chromium.org Review URL: https://codereview.chromium.org/1904463002 Cr-Commit-Position: refs/heads/master@{#35661}
-
yangguo authored
Short external strings do not cache the resource data, and may be used for compressible strings. The assumptions about their lengths is invalid and may lead to oob reads. R=jkummerow@chromium.org BUG=v8:4923,chromium:604897 LOG=N Review URL: https://codereview.chromium.org/1901573003 Cr-Commit-Position: refs/heads/master@{#35660}
-
mbrandy authored
Port 978ad03b Original commit message: Fix and re-enable the flexible representation for Math.floor (which is used to implement Math.ceil) and Math.round, which allows Math.floor and Math.round to return double results instead of int32, and therefore allows values outside the int32 range, especially -0 is now a valid result, which doesn't deopt. Also port this feature to x64 and ia32 when the CPU supports the SSE4.1 extension. This addresses all the known deoptimization loops related to Math.round in the Kraken benchmark suite, and seems to also address most of the deoptimization loops related to Math.floor in the Oort Online benchmark. Drive-by-fix: Import the regression tests for the broken HMathFloorOfDiv optimization that caused the initial revert of the feature (for arm64 only back then). R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=chromium:476477,v8:2890,v8:4059 LOG=n Review URL: https://codereview.chromium.org/1839643007 Cr-Commit-Position: refs/heads/master@{#35659}
-
jyan authored
Port d2b0a4b7 Original commit message: MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>; R= verwaest@chromium.org, joransiu@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com BUG= LOG=N Review URL: https://codereview.chromium.org/1902353002 Cr-Commit-Position: refs/heads/master@{#35658}
-
jyan authored
Port d412cfa2 Original commit message: [Atomics] Remove Atomics code stubs; use TF ops Reland of (https://codereview.chromium.org/1891033002) This is a much cleaner solution, which won't require nearly as much architecture-specific code. Thanks bmeurer@! R=binji@chromium.org, joransiu@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com BUG=v8:4614 LOG=N Review URL: https://codereview.chromium.org/1897373003 Cr-Commit-Position: refs/heads/master@{#35657}
-
mlippautz authored
BUG= Review URL: https://codereview.chromium.org/1899183002 Cr-Commit-Position: refs/heads/master@{#35656}
-
ahaas authored
Thereby we can get rid of the use of Typer and ChangeLowering in the wasm compiler. BUG=v8:4914 R=titzer@chromium.org, bmeurer@chromium.org LOG=N Review URL: https://codereview.chromium.org/1901063002 Cr-Commit-Position: refs/heads/master@{#35655}
-
hlopko authored
We need to empty the deque after EmbedderHeapTracer::TracePrologue, and we don't have to empty the deque after ProcessEphemeralMarking, as the deque should be empty already. BUG=468240 LOG=no Review URL: https://codereview.chromium.org/1900783002 Cr-Commit-Position: refs/heads/master@{#35654}
-
mstarzinger authored
In the long run we do not want to rely on compilation results being available on the CompilationInfo. This removes the accessor for the abstract code, which is very inviting to be used outside of compilation pipeline. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1903723002 Cr-Commit-Position: refs/heads/master@{#35653}
-
verwaest authored
Due to cross-compilation from simulator-builds into non-simulator with snapshot it's complicated to conditionally include an extra field. Given that the memory overhead should be minimal, just always include a separate field instead. BUG= Review URL: https://codereview.chromium.org/1901423002 Cr-Commit-Position: refs/heads/master@{#35652}
-
titzer authored
Also factor out test cases from test-run-machops.cc into test-run-load-store.cc BUG=chromium:599717 LOG=Y Review URL: https://codereview.chromium.org/1858323003 Cr-Commit-Position: refs/heads/master@{#35651}
-
vogelheim authored
BUG=chromium:604044 LOG=Y Review URL: https://codereview.chromium.org/1895123002 Cr-Commit-Position: refs/heads/master@{#35650}
-
mlippautz authored
In a full mark-compact GC, instead of copying memory to old space for pages that have more than X% live bytes, we just move the whole page over to old space. X=70 (default value) BUG=chromium:581412 LOG=N TBR=hpayer@chromium.org This reverts commit 8b333727. Review URL: https://codereview.chromium.org/1901093002 Cr-Commit-Position: refs/heads/master@{#35649}
-
zhengxing.li authored
port 81a1530e (r35642) original commit message: Before frame elision, we finalized the frame shape when assembling the prologue, which is also when we prepared the frame (saving sp, etc). The frame finalization only needs to happen once, and happens to be actually a set of idempotent operations. With frame elision, the logic for frame finalization was happening every time we constructed the frame. Albeit idempotent operations, the code would become hard to maintain. This change separates frame shape finalization from frame construction. When constructing the CodeGenerator, we finalize the frame. Subsequent access is to a const Frame*. Also renamed AssemblePrologue to AssembleConstructFrame, as suggested in the frame elision CR. Separating frame setup gave the opportunity to do away with architecture-independent frame aligning (which is something just arm64 cares about), and also with stack pointer setup (also arm64). Both of these happen now at frame finalization on arm64. additional message: This CL also removed the temporary workaround for CL #35139 (53d51c52) BUG= Review URL: https://codereview.chromium.org/1900213004 Cr-Commit-Position: refs/heads/master@{#35648}
-
mstarzinger authored
This moves the installation of the scope info object on the shared function info into a separate helper to share common code. This is preparatory work in order to reuse existing scope info objects. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1894023004 Cr-Commit-Position: refs/heads/master@{#35647}
-
mstarzinger authored
This removes some obsolete conditions checking whether we are performing concurrent OSR compilation. This feature has been removed some time ago. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1901163003 Cr-Commit-Position: refs/heads/master@{#35646}
-
hablich authored
Reland of Change calling convention of CallApiGetterStub to accept the AccessorInfo (patchset #1 id:1 of https://codereview.chromium.org/1906453002/ ) Reason for revert: Needs other reverts too. Original issue's description: > Revert of Change calling convention of CallApiGetterStub to accept the AccessorInfo (patchset #8 id:140001 of https://codereview.chromium.org/1892533004/ ) > > Reason for revert: > Blocks roll: https://codereview.chromium.org/1896103002/ > > Can also be seen on internal waterfall: https://chromegw.corp.google.com/i/internal.client.v8/builders/v8_cros_perf_1/builds/7558 > > Original issue's description: > > Change calling convention of CallApiGetterStub to accept the AccessorInfo > > > > MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com> > > > > Committed: https://crrev.com/d2b0a4b727f77f97960c7fa71da3431591dc959f > > Cr-Commit-Position: refs/heads/master@{#35606} > > TBR=rodolph.perfetta@arm.com,jkummerow@chromium.org,jacob.bramley@arm.com,verwaest@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true TBR=rodolph.perfetta@arm.com,jkummerow@chromium.org,jacob.bramley@arm.com,verwaest@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1903093003 Cr-Commit-Position: refs/heads/master@{#35645}
-
hablich authored
Revert of Change calling convention of CallApiGetterStub to accept the AccessorInfo (patchset #8 id:140001 of https://codereview.chromium.org/1892533004/ ) Reason for revert: Blocks roll: https://codereview.chromium.org/1896103002/ Can also be seen on internal waterfall: https://chromegw.corp.google.com/i/internal.client.v8/builders/v8_cros_perf_1/builds/7558 Original issue's description: > Change calling convention of CallApiGetterStub to accept the AccessorInfo > > MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com> > > Committed: https://crrev.com/d2b0a4b727f77f97960c7fa71da3431591dc959f > Cr-Commit-Position: refs/heads/master@{#35606} TBR=rodolph.perfetta@arm.com,jkummerow@chromium.org,jacob.bramley@arm.com,verwaest@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1906453002 Cr-Commit-Position: refs/heads/master@{#35644}
-
bmeurer authored
Previously we had to run SimplifiedLowering, ChangeLowering and JSGenericLowering independently and exactly in this order to achieve great performance for the common case of JSToNumber (i.e. input is already a Smi or a HeapNumber). This phase ordering problem already causes trouble with not being able to run the generic lowering phase earlier, but also blocks proper plain primitive ToNumber optimizations. So this properly integrates JSToNumber into the truncation analysis and optimizes according to the truncation (either Word32 or Float64). R=jarin@chromium.org Review URL: https://codereview.chromium.org/1901803002 Cr-Commit-Position: refs/heads/master@{#35643}
-