- 01 Dec, 2016 25 commits
-
-
marija.antic authored
Replace the sequence LUI+(D)ADD with (D)AUI BUG= Review-Url: https://codereview.chromium.org/2535703002 Cr-Commit-Position: refs/heads/master@{#41425}
-
ishell authored
... to avoid confusion. BUG= Review-Url: https://codereview.chromium.org/2546723002 Cr-Commit-Position: refs/heads/master@{#41424}
-
dusan.simicic authored
Trampolines are generated when the value of pc_offset is greater than next_buffer_check_ (attribute from Assembler class). This value shouldn't be incremented in bind_to() method when internal reference label is bound, because it is not decremented when the switch table is generated (dd() method from Assemler class). This patch fixes this problem. Regression test are also included for mips and mips64 arch. BUG= Review-Url: https://codereview.chromium.org/2530143002 Cr-Commit-Position: refs/heads/master@{#41423}
-
franzih authored
The loop for non-"static" properties is no longer needed in full-codegen since all computed property names in object literals go through Ignition first. BUG=v8:5657 Review-Url: https://codereview.chromium.org/2546473006 Cr-Commit-Position: refs/heads/master@{#41422}
-
jochen authored
Top level SharedFunctionInfos will end up in a scripts SFI list, but eval'd SFIs shouldn't. Separate IDs will allow for adding a corresponding DCHECK. BUG=v8:5589 R=marja@chromium.org Review-Url: https://codereview.chromium.org/2533303006 Cr-Commit-Position: refs/heads/master@{#41421}
-
mstarzinger authored
This fixes the existing workaround in {BytecodeGraphBuilder} where the number of elements in an array literal is unknown just from the bytecode alone and needs to be deduced from the constant elements. Note that this is just a quick fix to prevent calling the fast-clone stub for boilerplates that are too big to fit on a regular page. In the long run we need something more solid here. R=mvstanton@chromium.org TEST=mjsunit/regress/regress-crbug-669850 BUG=chromium:669850 Review-Url: https://codereview.chromium.org/2542633002 Cr-Commit-Position: refs/heads/master@{#41420}
-
zhengxing.li authored
Currently In LCodeGen::DoWrapReceiver(), the x87 jitted code's size for debug mode between label's define and bind exceeds 128 bytes whether FLAG_deopt_every_n_times is set or not. So always use Label:kFar as label distance in LCodeGen::DoWrapReceiver() for debug mode. This CL also unify the label's distance value to avoid potential bugs caused by unconsistent distance value usage for the same label when DeoptEveryNTimes() return true. BUG= Review-Url: https://codereview.chromium.org/2539403002 Cr-Commit-Position: refs/heads/master@{#41419}
-
jgruber authored
We can skip RegExpResult construction on the fast path for several functions to be more efficient. BUG=v8:5330,v8:5674 Review-Url: https://codereview.chromium.org/2543483003 Cr-Commit-Position: refs/heads/master@{#41418}
-
ishell authored
Bonus: fixed a couple of places where 32-bit comparison was used. BUG= Review-Url: https://codereview.chromium.org/2543873003 Cr-Commit-Position: refs/heads/master@{#41417}
-
bradnelson authored
Allow a function to be exported multiple times in a asm.js module. Remarkably, this had not been working before. BUG=670057 R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2535723009 Cr-Commit-Position: refs/heads/master@{#41416}
-
petermarshall authored
Unfortunately we have to split this up into two cases: those with exactly one spread argument as the final argument, and all others, due to any side-effects of evaluation being visible. This is in preparation for a new bytecode which handles super calls. BUG=v8:5659 Review-Url: https://codereview.chromium.org/2540593003 Cr-Commit-Position: refs/heads/master@{#41415}
-
jgruber authored
This refactors portions of exec into a new function without RegExpResult construction, which will be used in the future by test, @@match, and @@search fast paths. Unnecessary ToString and ToLength calls as well as repeated map checks were removed. BUG=v8:5339 Review-Url: https://codereview.chromium.org/2540153002 Cr-Commit-Position: refs/heads/master@{#41414}
-
mstarzinger authored
R=neis@chromium.org BUG=v8:5700 Review-Url: https://codereview.chromium.org/2538173002 Cr-Commit-Position: refs/heads/master@{#41413}
-
mstarzinger authored
This ensure that all inline allocations generated by {JSCreateLowering} will fit into a regular heap page. Allocations targeting LO-space must be done via a slower runtime call. R=bmeurer@chromium.org BUG=chromium:669850 Review-Url: https://codereview.chromium.org/2533353003 Cr-Commit-Position: refs/heads/master@{#41412}
-
clemensh authored
The current CHECK/DCHECK implementation fails statically if a signed value is compared against an unsigned value. The common solution is to cast on each caller, which is tedious and error-prone (might hide bugs). This CL implements signed vs. unsigned comparisons by executing up to two comparisons. For example, if i is int32_t and u is uint_32_t, a DCHECK_LE(i, u) would create the check i <= 0 || static_cast<uint32_t>(i) <= u. For checks against constants, at least one of the checks can be removed by compiler optimizations. The tradeoff we have to make is to sometimes silently execute an additional comparison. And we increase code complexity of course, even though the usage is just as easy (or even easier) as before. The compile time impact seems to be minimal: I ran 3 full compilations for Optdebug on my local machine, one time on the current ToT, one time with this CL plus http://crrev.com/2524093002. Before: 143.72 +- 1.21 seconds Now: 144.18 +- 0.67 seconds In order to check that the new comparisons are working, I refactored some DCHECKs in wasm to use the new magic, and added unit test cases. R=ishell@chromium.org, titzer@chromium.org CC=ahaas@chromium.org, bmeurer@chromium.org Committed: https://crrev.com/5925074a9dab5a8577766545b91b62f2c531d3dc Review-Url: https://codereview.chromium.org/2526783002 Cr-Original-Commit-Position: refs/heads/master@{#41275} Cr-Commit-Position: refs/heads/master@{#41411}
-
machenbach authored
BUG=chromium:603131 LOG=y Committed: https://crrev.com/6b9c49cac101d1a373ae1a098b7959f8aff848ac Review-Url: https://codereview.chromium.org/2533813002 Cr-Original-Commit-Position: refs/heads/master@{#41407} Cr-Commit-Position: refs/heads/master@{#41410}
-
machenbach authored
Revert of [build] Use MSVS 2015 by default. (patchset #5 id:80001 of https://codereview.chromium.org/2533813002/ ) Reason for revert: Breaks CI dbg builder: https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug%20builder/builds/13817 Original issue's description: > [build] Use MSVS 2015 by default. > > BUG=chromium:603131 > LOG=y > > Committed: https://crrev.com/6b9c49cac101d1a373ae1a098b7959f8aff848ac > Cr-Commit-Position: refs/heads/master@{#41407} TBR=jochen@chromium.org,vogelheim@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:603131 Review-Url: https://codereview.chromium.org/2538493007 Cr-Commit-Position: refs/heads/master@{#41409}
-
jgruber authored
This shows around a 2.2x speedup compared to the old JS implementation (and 3.5x compared to CPP) for the fast path. Adds ToUint32 to CodeStubAssembler. BUG=v8:5339 Review-Url: https://codereview.chromium.org/2532403002 Cr-Commit-Position: refs/heads/master@{#41408}
-
machenbach authored
BUG=chromium:603131 LOG=y Review-Url: https://codereview.chromium.org/2533813002 Cr-Commit-Position: refs/heads/master@{#41407}
-
ofrobots authored
R=franzih@chromium.org, kozyatinskiy@chromium.org, machenbach@chromium.org BUG= Review-Url: https://codereview.chromium.org/2540323003 Cr-Commit-Position: refs/heads/master@{#41406}
-
franzih authored
This code is no longer used in full-codegen since all computed property names in object literals go through Ignition first. BUG=v8:5657 Review-Url: https://codereview.chromium.org/2543643002 Cr-Commit-Position: refs/heads/master@{#41405}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/4e4ff82..ac12d5e Rolling v8/buildtools: https://chromium.googlesource.com/chromium/buildtools/+log/991f459..102c163 Rolling v8/third_party/android_tools: https://chromium.googlesource.com/android_tools/+log/811a2c3..b43a6a2 Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/2dd86f1..582ccd4 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/f81598c..ccd4a12 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review-Url: https://codereview.chromium.org/2538233003 Cr-Commit-Position: refs/heads/master@{#41404}
-
bradnelson authored
Incremental parsing of asm.js means we can see function tables that are unused in the AsmWasmBuilder before they've been initialized. BUG=669899 R=aseemgarg@chromium.org Review-Url: https://codereview.chromium.org/2546553002 Cr-Commit-Position: refs/heads/master@{#41403}
-
kozyatinskiy authored
This roll includes: - [inspector_protocol] always use weak pointer in DispatcherImpl::{command.name} [1] [1] https://codereview.chromium.org/2545613002/ BUG=chromium:668358 TBR=dgozman@chromium.org Review-Url: https://codereview.chromium.org/2541253002 Cr-Commit-Position: refs/heads/master@{#41402}
-
kozyatinskiy authored
If we just call CreateDebugInfo in GetPossibleBreakpoints then we won't call PrepareFunctionForBreakPoints and won't be able to step into this function or pause at breakpoint inside. BUG=v8:5695 R=dgozman@chromium.org,yangguo@chromium.org Review-Url: https://codereview.chromium.org/2540943002 Cr-Commit-Position: refs/heads/master@{#41401}
-
- 30 Nov, 2016 15 commits
-
-
eholk authored
During codegen, we build a list mapping protected instructions to their associated landing pads. This will ultimately by used by the signal handler to recover from out of bounds faults and throw a JS exception. This is mostly pulled from my larger in-progress CL at https://codereview.chromium.org/2371833007/. BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 Review-Url: https://codereview.chromium.org/2500443004 Cr-Commit-Position: refs/heads/master@{#41400}
-
tebbi authored
R=jarin@chromium.org BUG=v8:668517 Review-Url: https://codereview.chromium.org/2536353003 Cr-Commit-Position: refs/heads/master@{#41399}
-
eholk authored
This is necessary for signal-based out of bounds handling in WebAssembly. Adds a ProtectedStore instruction that is analogous to the previously added ProtectedLoad instruction. Rather than using bounds checks, ProtectedStore emits an out of line section of code that throws a JavaScript exception and provides the necessary metadata for a signal handler to be able to find the out of line code. BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 Review-Url: https://codereview.chromium.org/2516413003 Cr-Commit-Position: refs/heads/master@{#41398}
-
bbudge authored
Attempt to fix or get insight into failing vswp test on V8 ARM bot. LOG=N BUG= Review-Url: https://codereview.chromium.org/2539533005 Cr-Commit-Position: refs/heads/master@{#41397}
-
caitp authored
The "writable" property descriptor may legally change during the call to AnythingToArrayLength(). This change needs to be honoured before calling JSArray::SetLength(). The change is only honoured when the "length" property was previously writable, so that changes during a call to DefineOwnPropertyIgnoreAttributes() is ignored. BUG=v8:5688 R=cbruni@chromium.org, verwaest@chromium.org, jkummerow@chromium.org Review-Url: https://codereview.chromium.org/2543553002 Cr-Commit-Position: refs/heads/master@{#41396}
-
sampsong authored
BUG= R=jyan@ca.ibm.com,joransiu@ca.ibm.com,michael_dawson@ca.ibm.com,bjaideep@ca.ibm.com Review-Url: https://codereview.chromium.org/2536203003 Cr-Commit-Position: refs/heads/master@{#41395}
-
caitp authored
Before, we were treating objects with the builtin ArrayValues iterator method as array-like, where the iterator would iterate through to the full length of the object. This optimization was not sound, because it does not ensure that the next method hasn't been modified. Even if it hasn't been modified, it's entirely possible to be modified during iteration. Thus, this optimization has been removed due to its observability. BUG=v8:5699 R=littledan@chromium.org, cbruni@chromium.org Review-Url: https://codereview.chromium.org/2544503002 Cr-Commit-Position: refs/heads/master@{#41394}
-
leszeks authored
This was causing more confusion than benefit, so we're removing it. It's re-defined to empty for now, to avoid touching the ~100 files which use it, we can remove it completely during a quiet period when it's less likely to conflict with other work. Review-Url: https://codereview.chromium.org/2535383005 Cr-Commit-Position: refs/heads/master@{#41393}
-
neis authored
JS operators always have an implicit context input, so just use that instead. BUG= Review-Url: https://codereview.chromium.org/2541813002 Cr-Commit-Position: refs/heads/master@{#41392}
-
ulan authored
This is an experiment to see the impact of the limit on OOM crashes. BUG=chromium:667388 Review-Url: https://codereview.chromium.org/2514313004 Cr-Commit-Position: refs/heads/master@{#41391}
-
ishell authored
BUG=chromium:666947 Review-Url: https://codereview.chromium.org/2539013002 Cr-Commit-Position: refs/heads/master@{#41390}
-
jarin authored
BUG=chromium:669024 Review-Url: https://codereview.chromium.org/2531163006 Cr-Commit-Position: refs/heads/master@{#41389}
-
clemensh authored
These byte pointers (module_start and module_end) were only valid during decoding. During instantiation or execution, they can get invalidated by garbage collection. This CL removes them from the WasmModule struct, and introduces a new ModuleStorage struct as interface to the wasm wire bytes. Since the storage is often needed together with the ModuleEnv, a new ModuleStorageEnv struct holds both a ModuleEnv and a ModuleStorage. The pointers in the ModuleStorage should never escape the live range of this struct, as they might point into a SeqOneByteString or ArrayBuffer. Therefore, the WasmInterpreter needs to create its own copy of the whole module. Runtime functions that previously used the raw pointers in WasmModule (leading to memory errors) now have to use the SeqOneByteString in the WasmCompiledModule. R=titzer@chromium.org BUG=chromium:669518 Review-Url: https://codereview.chromium.org/2540133002 Cr-Commit-Position: refs/heads/master@{#41388}
-
rmcilroy authored
JSFrameSpecialization depends on the layout of the frame and doesn't work with interpreted frames. Disable it since it is only used for OSR from asmjs code, which shouldn't go through the bytecode graph builder in many cases. BUG=669517 Review-Url: https://codereview.chromium.org/2538823002 Cr-Commit-Position: refs/heads/master@{#41387}
-
jochen authored
Also move them to a separate interface header to avoid having to include parser.h so much BUG=v8:5589 R=verwaest@chromium.org,marja@chromium.org Review-Url: https://codereview.chromium.org/2534393002 Cr-Commit-Position: refs/heads/master@{#41386}
-