- 21 Apr, 2016 20 commits
-
-
verwaest authored
BUG= Review URL: https://codereview.chromium.org/1912553002 Cr-Commit-Position: refs/heads/master@{#35699}
-
titzer authored
R=jfb@chromium.org,rossberg@chromium.org BUG= Review URL: https://codereview.chromium.org/1900153002 Cr-Commit-Position: refs/heads/master@{#35698}
-
verwaest authored
BUG=chromium:605060 LOG=n Review URL: https://codereview.chromium.org/1907953002 Cr-Commit-Position: refs/heads/master@{#35697}
-
epertoso authored
Adds a Generate method to the stubs that can be used to embed the graph directly in the bytecode handlers. Review URL: https://codereview.chromium.org/1902823002 Cr-Commit-Position: refs/heads/master@{#35696}
-
titzer authored
R=bradnelson@chromium.org,aseemgarg@chromium.org BUG= Review URL: https://codereview.chromium.org/1909513002 Cr-Commit-Position: refs/heads/master@{#35695}
-
mstarzinger authored
This check whether a function is being debugged is obsolete. For the optimization path it is covered by a bailout further down. The lookup within the optimized code map doesn't need to be covered, because that map is guaranteed to stay empty while break slots are present. R=mvstanton@chromium.org Review URL: https://codereview.chromium.org/1907923003 Cr-Commit-Position: refs/heads/master@{#35694}
-
ishell authored
[deoptimizer] Do not modify stack_fp which is used as a key for lookup of previously materialized objects. BUG=chromium:604680, v8:4698 LOG=N Review URL: https://codereview.chromium.org/1904663003 Cr-Commit-Position: refs/heads/master@{#35693}
-
jochen authored
BUG=v8:4933 R=verwaest@chromium.org LOG=n Review URL: https://codereview.chromium.org/1899283003 Cr-Commit-Position: refs/heads/master@{#35692}
-
clemensh authored
Since traps now throw real Error objects, we get stack traces containing <WASM> functions on top-level. The additional tests check for two traps: unreachable and memory out-of-bounds. R=ahaas@chromium.org, jfb@chromium.org, titzer@chromium.org BUG= Review URL: https://codereview.chromium.org/1878563003 Cr-Commit-Position: refs/heads/master@{#35691}
-
v8-autoroll authored
Rolling v8/buildtools to e84114dbe2b65428951c876349b6a3ff1afbfccd Rolling v8/tools/clang to 2956eca572ff0e1b181df65f71a045f061a2eb34 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review URL: https://codereview.chromium.org/1909483004 Cr-Commit-Position: refs/heads/master@{#35690}
-
zhengxing.li authored
The CL #35651 (https://codereview.chromium.org/1858323003) exposed one hiden issue in RunTruncateFloat32ToUint32 test cases and X87 failed at it. Here is the issue in RunTruncateFloat32ToUint32: For float input = static_cast<float>(*i), the x87 GCC would optimize the input viariable in float floating register for release build. The problem is: SSE float register has single precision rounding semantic While X87 register hasn't when directly use floating register value. It will cause the value of input viariable has different precision for IA32 and X87 port. So static_cast<uint32_t>(input) will be different for IA32 and X87 port too. This led to CHECK_EQ(static_cast<uint32_t>(input), m.Call(input)) fail although V8 turbofan JITTed code m.Call(input) has exactly same result in both X87 and IA32 port. So we add the following sentence to do type cast to keep the single precision for RunTruncateFloat32ToUint32 by forcing the input viariable get value from memory insread of floating register. Such as: volatile float input = static_cast<float>(*i). BUG= Review URL: https://codereview.chromium.org/1905883002 Cr-Commit-Position: refs/heads/master@{#35689}
-
machenbach authored
BUG=v8:4928 LOG=n NOTRY=true Review URL: https://codereview.chromium.org/1903043006 Cr-Commit-Position: refs/heads/master@{#35688}
-
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=machenbach@chromium.org, jfb@chromium.org, titzer@chromium.org Review URL: https://codereview.chromium.org/1875153002 Cr-Commit-Position: refs/heads/master@{#35687}
-
machenbach authored
The external snapshot target is missing a few build dependencies. TBR=vogelheim@chromium.org, yangguo@chromium.org, clemensh@chromium.org Review URL: https://codereview.chromium.org/1904013002 Cr-Commit-Position: refs/heads/master@{#35686}
-
ahaas authored
This patch provides a new implementation of popcnt and ctz in the case where the platform does not provide these instructions. Instead of building a TF graph which implements it we now call a C function. Additionally I turned on additional tests in test-run-wasm-64.cc R=titzer@chromium.org Review URL: https://codereview.chromium.org/1857363003 Cr-Commit-Position: refs/heads/master@{#35685}
-
danno authored
Move allocation-related and smi un/tagging methods into CodeStubAssembler. Review URL: https://codereview.chromium.org/1893383002 Cr-Commit-Position: refs/heads/master@{#35684}
-
yangguo 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=bmeurer@chromium.org BUG=v8:4923,chromium:604897 LOG=N Review URL: https://codereview.chromium.org/1902393004 Cr-Commit-Position: refs/heads/master@{#35683}
-
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 20 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}
-