- 30 Jun, 2015 24 commits
-
-
conradw authored
Revert "Revert relanded strong property access CL" Regression issues should be solved. Initial patchset is the original, subsequent patchsets are the fixing modifications. This reverts commit 4ac7be56. BUG=v8:3956 LOG=N Review URL: https://codereview.chromium.org/1199983002 Cr-Commit-Position: refs/heads/master@{#29384}
-
jochen authored
Revert of Let GC select the collector when the external memory allocation limit is reached (patchset #1 id:1 of https://codereview.chromium.org/1201993002/) Reason for revert: results in a scavenge storm if scavenge doesn't free enough memory Original issue's description: > Let GC select the collector when the external memory allocation limit is reached > > BUG=none > R=hpayer@chromium.org > LOG=n > > Committed: https://crrev.com/93d6216099b60e95bc816bcc913f8f841ee795b6 > Cr-Commit-Position: refs/heads/master@{#29235} TBR=hpayer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=none Review URL: https://codereview.chromium.org/1215513004 Cr-Commit-Position: refs/heads/master@{#29383}
-
mbrandy authored
R=dstence@us.ibm.com, michael_dawson@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1216073004 Cr-Commit-Position: refs/heads/master@{#29382}
-
conradw authored
Also fixes a crankshaft bug with strong implicit conversions. It turns out that the implicit conversion of oddball values is smushed into so many places in crankshaft that it would have been pretty invasive surgery to make everything fall out naturally. BUG=v8:3956 LOG=N Review URL: https://codereview.chromium.org/1216463003 Cr-Commit-Position: refs/heads/master@{#29381}
-
martyn.capewell authored
Move the arithmetic shift from Int32MulHigh to a following Int32Add on ARM64. This graph is commonly generated on reduction of signed integer division. Review URL: https://codereview.chromium.org/1209413008 Cr-Commit-Position: refs/heads/master@{#29380}
-
hpayer authored
BUG= Review URL: https://codereview.chromium.org/1221643004 Cr-Commit-Position: refs/heads/master@{#29379}
-
akos.palfi authored
This change makes possible to save and restore the FP registers in the Prologue and Return parts for the CallAddress kind functions. TEST=test-simplified-lowering/RunNumberDivide_2_TruncatingToUint32, test-simplified-lowering/RunNumberMultiply_TruncatingToUint32 Review URL: https://codereview.chromium.org/1191513003 Cr-Commit-Position: refs/heads/master@{#29378}
-
jochen authored
BUG=chromium:504875 R=hpayer@chromium.org LOG=n Review URL: https://codereview.chromium.org/1215103003 Cr-Commit-Position: refs/heads/master@{#29377}
-
bmeurer authored
R=jarin@chromium.org Review URL: https://codereview.chromium.org/1213383002 Cr-Commit-Position: refs/heads/master@{#29376}
-
hablich authored
R=machenbach@chromium.org BUG=v8:4135 NOTRY=true LOG=N Review URL: https://codereview.chromium.org/1217993002 Cr-Commit-Position: refs/heads/master@{#29375}
-
bmeurer authored
The deoptimizer (and probably various other places) cannot deal properly with recursive function inlining, so we disallow it in TurboFan as well. We might want to reconsider that decision at some point in the future. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1211243007 Cr-Commit-Position: refs/heads/master@{#29374}
-
yangguo authored
R=ulan@chromium.org Review URL: https://codereview.chromium.org/1214303002 Cr-Commit-Position: refs/heads/master@{#29373}
-
mstarzinger authored
Reland of https://crrev.com/bf2bbc8ba508ccd21edf3c08d2e4192c4764ae91 R=bmeurer@chromium.org TEST=mjsunit/regress/regress-crbug-498022 BUG=chromium:498022 LOG=N Review URL: https://codereview.chromium.org/1214483008 Cr-Commit-Position: refs/heads/master@{#29372}
-
mvstanton authored
BUG= Review URL: https://codereview.chromium.org/1213773002 Cr-Commit-Position: refs/heads/master@{#29371}
-
yangguo authored
R=mvstanton@chromium.org BUG=v8:4132 LOG=N Review URL: https://codereview.chromium.org/1214953003 Cr-Commit-Position: refs/heads/master@{#29370}
-
ishell authored
BUG=chromium:505007 LOG=N Review URL: https://codereview.chromium.org/1219693003 Cr-Commit-Position: refs/heads/master@{#29369}
-
jarin authored
Also removed some unused classes. BUG= Review URL: https://codereview.chromium.org/1212643010 Cr-Commit-Position: refs/heads/master@{#29368}
-
yangguo authored
This has become necessary as we have more experimental natives that run after deserializing from the snapshot. R=hpayer@chromium.org BUG=v8:4200 LOG=N Review URL: https://codereview.chromium.org/1218973002 Cr-Commit-Position: refs/heads/master@{#29367}
-
bmeurer authored
Ideally inliner itself should not deal with context specialization at all, since this is all handled in the pipeline instead (actually inlining already runs together with context specialization), and the inlining logic should not care about the specialization mode. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1217973003 Cr-Commit-Position: refs/heads/master@{#29366}
-
bmeurer authored
This optimization never triggers currently, and is inherently native context dependent for no real reason (for example it will not properly detect those constructors in the case of cross native context inlining), plus it is slow and awkward. In case we really need this functionality at some point, we should find a way to make it work with the builtin function id mechanism that is already in place to match other builtins. R=jarin@chromium.org,rossberg@chromium.org Review URL: https://codereview.chromium.org/1221683006 Cr-Commit-Position: refs/heads/master@{#29365}
-
bmeurer authored
R=jarin@chromium.org Review URL: https://codereview.chromium.org/1221753002 Cr-Commit-Position: refs/heads/master@{#29364}
-
yangguo authored
TBR=brucedawson@chromium.org Review URL: https://codereview.chromium.org/1212613006 Cr-Commit-Position: refs/heads/master@{#29363}
-
mstarzinger authored
This makes sure that the exit control flow that merges the try-block with the catch-block after a try-catch-statement creates a new merge node in cases where it has to. Otherwise dangling phi nodes might have the wrong number of value inputs. R=bmeurer@chromium.org TEST=mjsunit/regress/regress-crbug-505354 BUG=chromium:505354 LOG=N Review URL: https://codereview.chromium.org/1213183003 Cr-Commit-Position: refs/heads/master@{#29362}
-
littledan authored
The failure was been triggered by turning on --harmony-arrays, maybe because code size was increased or code was added later in the bootstrap process. Because it doesn't look like a bug in anything guarded by --harmony-arrays directly, I'd suggest shipping the flag and disabling the test on the architectures where it's been observed to fail. It's already disabled on arm64 and this patch disables it on mips64 as well. BUG=v8:4200 LOG=N R=adamk Review URL: https://codereview.chromium.org/1212963004 Cr-Commit-Position: refs/heads/master@{#29361}
-
- 29 Jun, 2015 16 commits
-
-
mbrandy authored
Port 7a63bf77 Original commit message: This makes new.target work in [[Call]] and [[Construct]] of ordinary functions. We achieve this by introducing a new construct stub for functions that uses the new.target variable. The construct stub pushes the original constructor just above the receiver in the construct frame. R=arv@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1213303002 Cr-Commit-Position: refs/heads/master@{#29360}
-
arv authored
BUG=v8:3887 LOG=N R=caitpotter88@gmail.com, adamk@chromium.org Review URL: https://codereview.chromium.org/1215973005 Cr-Commit-Position: refs/heads/master@{#29359}
-
arv authored
This makes new.target work in [[Call]] and [[Construct]] of ordinary functions. We achieve this by introducing a new construct stub for functions that uses the new.target variable. The construct stub pushes the original constructor just above the receiver in the construct frame. BUG=v8:3887 LOG=N R=adamk@chromium.org, dslomov@chromium.org Review URL: https://codereview.chromium.org/1203813002 Cr-Commit-Position: refs/heads/master@{#29358}
-
arv authored
We were calling the setter for Object.prototype.promise if it existed when calling PromiseAll. BUG=v9:4232 LOG=N R=rossberg@chromium.org, adamk@chromium.org Review URL: https://codereview.chromium.org/1219623005 Cr-Commit-Position: refs/heads/master@{#29357}
-
paul.lind authored
zlib is broken for mips after 35eb3a02. We're still working on a fix. Skip test for now, so the bots cycle green. BUG= Review URL: https://codereview.chromium.org/1209253005 Cr-Commit-Position: refs/heads/master@{#29356}
-
oth authored
BUG=chromium:505228 LOG=Y Review URL: https://codereview.chromium.org/1219723002 Cr-Commit-Position: refs/heads/master@{#29355}
-
yangguo authored
Only this way we can precisely determine how to allocate let variables inside the scope. R=rossberg@chromium.org BUG=v8:4255 LOG=N Review URL: https://codereview.chromium.org/1216013002 Cr-Commit-Position: refs/heads/master@{#29354}
-
dusan.milosavljevic authored
Enable skipped test-api/RequestInterruptTestWith* after: https://codereview.chromium.org/1220443002/ TEST= BUG= Review URL: https://codereview.chromium.org/1219683004 Cr-Commit-Position: refs/heads/master@{#29353}
-
mtrofin authored
Separated core greedy allocator concepts, exposing the APIs we would want to continue working with. In particular, this change completely reworks CoalescedLiveRanges to reflect the fact that we expect more than one possible conflict, scrapping the initial design of the structure. Since this is a critical part of the design, this change may be thought of as a full rewrite of the algorithm. Reduced all heuristics to just 2 essential ones: split "somewhere", which we'll still need when all other heuristics fail; and spill. Introduced a simple primitive for splitting - at GapPosition::START. The goal is to use such primitives to quickly and reliably author heuristics. I expected this primitive to "just work" for any arbitrary instruction index within a live range - e.g. its middle. That's not the case, it seems to upset execution in certain scenarios. Restricting to either before/after use positions seems to work. I'm still investigating what the source of failures is in the case of "arbitrary instruction in the range" case. I intended to document the rationale and prove the soundness of always using START for splits, but I will postpone to after this last remaining issue is resolved. Review URL: https://codereview.chromium.org/1205173002 Cr-Commit-Position: refs/heads/master@{#29352}
-
binji authored
This one occurs when Function.prototype.toString is overridden to return a non-string. BUG=chromium:504729 R=mstarzinger@chromium.org LOG=n Review URL: https://codereview.chromium.org/1214803004 Cr-Commit-Position: refs/heads/master@{#29351}
-
binji authored
Dumb typo introduced in refs/heads/master@{#29306}. I thought I was turning on report_exceptions in Shell::ExecuteString, but instead I turned on print_result (which assumes an interactive debugger and a HandleScope for the utility_context_). BUG=chromium:504727,chromium:504728 R=mstarzinger@chromium.org LOG=n Review URL: https://codereview.chromium.org/1219563002 Cr-Commit-Position: refs/heads/master@{#29350}
-
machenbach authored
The android_* configs were never real v8 target architectures, only make targets. This doesn't make sense with ninja anymore. BUG=chromium:502176 LOG=n NOTRY=true Review URL: https://codereview.chromium.org/1220743002 Cr-Commit-Position: refs/heads/master@{#29349}
-
ishell authored
BUG=chromium:505367 LOG=N Review URL: https://codereview.chromium.org/1215003002 Cr-Commit-Position: refs/heads/master@{#29348}
-
Djordje.Pesic authored
RegExpCompileEvent acquieres mutex from Log class during MessageBuilder creation. LogRegExpSource, called from RegExpCompileEvent creates another MessageBuilder object which also acquires the same mutex. This mutex is not recursive, so during second acquirement, assertion fail is happening. Solution: LogRegExpSource should use the same MessageBuilder object as RegExpCompileEvent. Review URL: https://codereview.chromium.org/1207433002 Cr-Commit-Position: refs/heads/master@{#29347}
-
oth authored
BUG=505228 LOG=Y Review URL: https://codereview.chromium.org/1210153003 Cr-Commit-Position: refs/heads/master@{#29346}
-
machenbach authored
Revert of Use third_party clang on Mac. (patchset #4 id:60001 of https://codereview.chromium.org/1200833013/) Reason for revert: [Sheriff] Breaks mac on the main waterfall (though not on the tryserver): http://build.chromium.org/p/client.v8/builders/V8%20Mac64/builds/3925 Original issue's description: > Use third_party clang on Mac. > > BUG= > > Committed: https://crrev.com/57b20413294940476ab2b2e71ed0802aaf8c223f > Cr-Commit-Position: refs/heads/master@{#29343} TBR=danno@chromium.org,jkummerow@chromium.org,paul.lind@imgtec.com,akos.palfi@imgtec.com,balazs.kilvady@imgtec.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1217823003 Cr-Commit-Position: refs/heads/master@{#29345}
-