- 11 Jun, 2013 10 commits
-
-
plind44@gmail.com authored
test-thread-termination/TerminateMultipleV8ThreadsDefaultIsolate times out on the MIPS simulator. Allow the timeouts until this is fixed. BUG=v8:2657 R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/16203005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15063 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
plind44@gmail.com authored
Add barriers using MIPS 'sync' instructions as needed for SMP systems. BUG=246947 R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/15981017 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
This includes r15032, r15030 and r15005. R=ulan@chromium.org BUG=248076 Review URL: https://chromiumcodereview.appspot.com/16482004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15061 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
jkummerow@chromium.org authored
- set "can be minus zero" flag properly so minus-zero checks are skipped - skip "integer result?" check in division code when uses are truncating - drive-by cleanup: consolidated computation of kCanOverflow flag for Add/Sub into range inference phase BUG=v8:2132 R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/16741002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15060 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
wingo@igalia.com authored
Also fix a typo in an assertion in scanner.h. R=mstarzinger@chromium.org BUG=248025 TEST=mjsunit/regress/regress-crbug-248025.js Review URL: https://codereview.chromium.org/16549003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15059 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
dcarney@chromium.org authored
R=svenpanne@chromium.org BUG= Review URL: https://codereview.chromium.org/16537005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15058 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
jkummerow@chromium.org authored
- In the INT32 BinaryOpStub, fix type feedback collection for DIV, bringing it in line with other platforms. - In Lithium codegen, emit proper inlined code, don't call the stub. - Drive-by fix: assert appropriate CpuFeaturesScope for SDIV. R=ulan@chromium.org Review URL: https://codereview.chromium.org/16082008 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15057 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
dslomov@chromium.org authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/15855012 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15056 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
Changed cctest/test-cpu-profiler/NativeAccessorNameInProfile2 to make a few warm-up cycles before starting profiler so that accessor invocations performed via monomorphic inline caches and slow paths traces do not distort the profile. Drive-by: removed logging code that was used to diagnose NativeAccessorNameInProfile2 failures on Windows. BUG=None R=jkummerow@chromium.org, loislo@chromium.org Review URL: https://codereview.chromium.org/16758007 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15055 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
dcarney@chromium.org authored
R=svenpanne@chromium.org BUG= Review URL: https://codereview.chromium.org/16621004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15054 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 10 Jun, 2013 28 commits
-
-
palfia@homejinni.com authored
The abs_d instruction was implemented wrongly in the simulator, it doesn't reverse the sign of the -0 number. This commit fixes the abs_d instruction implementation. TEST=msjunit/math-abs BUG= Review URL: https://codereview.chromium.org/15906014 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15053 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
palfia@homejinni.com authored
Port r15045 (cce366f) Original commit message: Strict-equality only has one check and cannot deopt. Should therefore not be part of the stub. BUG= Review URL: https://codereview.chromium.org/16690008 Patch from Balazs Kilvady <kilvadyb@homejinni.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15050 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
palfia@homejinni.com authored
Port r15028 (258a047) Original commit message: Update the generators implementation to make "next" also do the job of what was previously called "send" by taking an optional argument. Remove send, and do a bunch of renamings. BUG=v8:2355, v8:2715 Review URL: https://codereview.chromium.org/16735005 Patch from Balazs Kilvady <kilvadyb@homejinni.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15049 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
palfia@homejinni.com authored
Port r15027 (3ffb343) Original commit message: The comments in ic-arm.cc::LoadIC indicated that the receiver should be both in a register and on the stack. This isn't true in fact: the code is careful to spill the receiver if needed. This CL also fixes up a mistaken use of this convention in VisitYield. BUG= Review URL: https://codereview.chromium.org/16131004 Patch from Balazs Kilvady <kilvadyb@homejinni.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15048 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
palfia@homejinni.com authored
Port r15024 (1a76177) BUG= Review URL: https://codereview.chromium.org/16005015 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15047 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
r14919 forgot three AssertNoAllocation -> DisallowHeapAllocation replacements. BUG=v8:2719 R=yangguo@chromium.org Review URL: https://chromiumcodereview.appspot.com/16093041 Patch from Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15046 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
olivf@chromium.org authored
use compare nil ic only for non-strict equality. strict-equality only has one check and cannot deopt. should therefore not be part of the stub. BUG= R=rossberg@chromium.org Review URL: https://codereview.chromium.org/16732002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15045 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
olivf@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15044 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
olivf@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15043 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
olivf@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15042 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
verwaest@chromium.org authored
R=jkummerow@chromium.org BUG= Review URL: https://chromiumcodereview.appspot.com/16730004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15039 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mvstanton@chromium.org authored
Array access fix: g++ darwin 4.2.1 compiler clamped array index to 0 when confronted with negative indices. BUG=247303 R=jkummerow@chromium.org, ulan@chromium.org Review URL: https://codereview.chromium.org/15855015 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15038 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
hpayer@chromium.org authored
This change results in less scan on scavenge memory chunks. BUG= R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/15896037 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15037 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
wingo@igalia.com authored
R=yangguo@chromium.org BUG= Review URL: https://codereview.chromium.org/16436005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15036 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
wingo@igalia.com authored
The previous patch that renamed _GeneratorSend to _GeneratorNext missed the blacklist in fuzz-natives-part4. R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/16339008 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15035 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
svenpanne@chromium.org authored
Depending on what we know about the right operand, we basically do 3 different things (and the code is actually structured this way): * If we statically know that the right operand is a power of 2, we do some bit fiddling instead of doing a "real" modulus calculation. This should actually be done on the Hydrogen level, not on the Lithium level, but this will be a separate CL. * If type feedback tells us that the right operand is a power of 2, we do the same as above, but guarded by conditional deoptimization to make sure that the assumption is still valid. In the long run, we should make this guard visible on the Hydrogen level to make it visible for GVN and other optimizations. * In the general case we only do the minimum steps necessary and don't try to be too clever, because cleverness actually slows us down on real-world code. If we look at the code gerators for LModI, we actually see that we basically have 3 (4 on ARM) fundamentally different translations. I don't really like lumping them together, they should probably be different Lithium instructions. For the time being, I restructured the generators to make this crystal-clear, at the cost of some duplication regarding the power-of-2 cases. This will go away when we do the strength reduction on the Hydrogen level, so I'd like to keep it as it is for now. Note that the MIPS part was only slightly restructured, there is still some work to do there. R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/15769010 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15034 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mstarzinger@chromium.org authored
R=verwaest@chromium.org BUG=v8:2717 TEST=mjsunit/regress/regress-2717 Review URL: https://codereview.chromium.org/16735003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15033 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
R=ulan@chromium.org BUG= Review URL: https://chromiumcodereview.appspot.com/15896038 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15032 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
verwaest@chromium.org authored
R=ulan@chromium.org BUG=chromium:242332 Review URL: https://chromiumcodereview.appspot.com/16347005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15031 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
R=ulan@chromium.org BUG= Review URL: https://chromiumcodereview.appspot.com/16641002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15030 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
dcarney@chromium.org authored
R=svenpanne@chromium.org BUG= Review URL: https://codereview.chromium.org/16136012 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15029 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
wingo@igalia.com authored
Update the generators implementation to make "next" also do the job of what was previously called "send" by taking an optional argument. Remove send, and do a bunch of renamings. R=rossberg@chromium.org BUG=v8:2355, v8:2715 Review URL: https://codereview.chromium.org/16136011 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15028 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
wingo@igalia.com authored
The comments in ic-arm.cc::LoadIC indicated that the receiver should be both in a register and on the stack. This isn't true in fact: the code is careful to spill the receiver if needed. This CL also fixes up a mistaken use of this convention in in VisitYield. R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/16203004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15027 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
dcarney@chromium.org authored
R=yangguo@chromium.org BUG= Review URL: https://codereview.chromium.org/16561011 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15026 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
dcarney@chromium.org authored
R=yangguo@chromium.org BUG= Review URL: https://codereview.chromium.org/16729002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15025 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
dcarney@chromium.org authored
R=svenpanne@chromium.org BUG= Review URL: https://codereview.chromium.org/16642003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15024 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
dcarney@chromium.org authored
R=yangguo@chromium.org BUG= Review URL: https://codereview.chromium.org/16147004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15023 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
svenpanne@chromium.org authored
TBR=yangguo@google.com Review URL: https://codereview.chromium.org/16544009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15022 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 Jun, 2013 1 commit
-
-
peter.rybin@gmail.com authored
Current approach is to find breakpoint by the statement position that was used when setting breakpoint. This doesn't work when setting breakpoint by anything else but statement position. (Question: could PC of existing breakpoint change, for example because of recompilation, or this approach is safe) R=yangguo@chromium.org Review URL: https://codereview.chromium.org/15685010 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15021 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 Jun, 2013 1 commit
-
-
machenbach@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15018 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-