- 13 Nov, 2015 12 commits
-
-
mythria authored
Adds an optimization to omit generating Ldar/Star if the same register is loaded or stored from the accumulator in the earlier instruction. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1435283002 Cr-Commit-Position: refs/heads/master@{#31984}
-
cbruni authored
LOG=N BUG=v8:1543 Review URL: https://codereview.chromium.org/1417063011 Cr-Commit-Position: refs/heads/master@{#31983}
-
mstarzinger authored
This makes sure that inlining a constructor call to a function which cannot be used as a constructor (e.g. strong mode function) still does throw correctly when the implicit receiver is created. R=bmeurer@chromium.org TEST=mjsunit/regress/regress-inline-strong-as-construct BUG=v8:4544 LOG=n Review URL: https://codereview.chromium.org/1447443002 Cr-Commit-Position: refs/heads/master@{#31982}
-
rossberg authored
This reverts commit b7db5cd9 (https://codereview.chromium.org/1324353002/). Our internal dashboard shows that this patch has introduced massive (3x) performance regressions for string ops. This is probably due to it repeatedly invoking %_StringCharCodeAt in a loop, which is far from cheap (has to dispatch on one of our 30+ string representations each time). TBR=dehrenberg@chromium.org BUG= Review URL: https://codereview.chromium.org/1439083003 Cr-Commit-Position: refs/heads/master@{#31981}
-
ishell authored
1) Body descriptors moved to their own header files. 2) Missing body descriptors added. 3) Template versions of HeapObject::Iterate*() methods added. 4) Body descriptors support new kind of queries: IsValidSlot(offset) which can be used for invalid slots filtering. This is a first step towards virtual and static visitors unification and support in-object properties in built-in (sub-)classes. Review URL: https://codereview.chromium.org/1440243002 Cr-Commit-Position: refs/heads/master@{#31980}
-
bmeurer authored
The JSCallReducer runs together with inlining and tries to strength reduce JSCallFunction nodes; currently it can fold Function.prototype.call and Function.prototype.apply (with arguments), and make it possible to inline across them. In the case of Function.prototype.apply with arguments we still have to leave the JSCreateArguments node in the graph because there might be other (frame state) uses. Once escape analysis is ready, it will take care of removing these nodes and adding appropriate transitions for the deoptimizer. R=jarin@chromium.org BUG=v8:4551 LOG=n Review URL: https://codereview.chromium.org/1445513002 Cr-Commit-Position: refs/heads/master@{#31979}
-
mstarzinger authored
This aligns the naming of "new target" with the spec text throughout TurboFan and the stack frame walker. The goal is to avoid unnecessary confusion for people familiar with the spec. R=verwaest@chromium.org Review URL: https://codereview.chromium.org/1442643002 Cr-Commit-Position: refs/heads/master@{#31978}
-
yangguo authored
R=verwaest@chromium.org BUG=chromium:554946 LOG=N Review URL: https://codereview.chromium.org/1442963002 Cr-Commit-Position: refs/heads/master@{#31977}
-
jarin authored
This is necessary to allow more optimizations to take place between the representation inference and change lowering. Perhaps we want to rename SimplifiedLowering -> RepresentationInference and ChangeLowering -> SimplifiedLowering. Review URL: https://codereview.chromium.org/1439473003 Cr-Commit-Position: refs/heads/master@{#31976}
-
bmeurer authored
Continue with the other candidates in case of a failed attempt to inline a certain candidate. TBR=mstarzinger@chromium.org BUG=v8:4493 LOG=n Review URL: https://codereview.chromium.org/1435373002 Cr-Commit-Position: refs/heads/master@{#31975}
-
v8-autoroll authored
Rolling v8/buildtools to 3ba3ca22ec610fe95683f6bfdeea9d90c768abd7 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review URL: https://codereview.chromium.org/1436393003 Cr-Commit-Position: refs/heads/master@{#31974}
-
akos.palfi authored
Port 857cd4c1 BUG= Review URL: https://codereview.chromium.org/1439053003 Cr-Commit-Position: refs/heads/master@{#31973}
-
- 12 Nov, 2015 21 commits
-
-
neis authored
BUG= Review URL: https://codereview.chromium.org/1427743011 Cr-Commit-Position: refs/heads/master@{#31972}
-
caitpotter88 authored
BUG=v8:4360 LOG=N R=littledan@chromium.org Review URL: https://codereview.chromium.org/1440593003 Cr-Commit-Position: refs/heads/master@{#31971}
-
mlippautz authored
R=hpayer@chromium.org Review URL: https://codereview.chromium.org/1438313002 Cr-Commit-Position: refs/heads/master@{#31970}
-
ahaas authored
The least significant bit of the input value may affect the result of the conversion through rounding. We OR the least significant with the second least significant bit to preserve it over the SHR instruction. R=titzer@chromium.org Review URL: https://codereview.chromium.org/1435203003 Cr-Commit-Position: refs/heads/master@{#31969}
-
yangguo authored
BUG=chromium:554946 LOG=y R=jkummerow@chromium.org, jochen@chromium.org Review URL: https://codereview.chromium.org/1435083003 Cr-Commit-Position: refs/heads/master@{#31968}
-
mbrandy authored
This test, as written, is invalid on platforms which use function descriptors. See https://codereview.chromium.org/1377423002/ for background. R=mstarzinger@chromium.org, titzer@chromium.org, michael_dawson@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1438803002 Cr-Commit-Position: refs/heads/master@{#31967}
-
adamk authored
Because the Scope will be optimized away by the call to FinalizeBlockScope in the case where there are no lexical declarations in the block, this should have no effect on anything downstream from the Parser, and simply removes duplicate parsing code. Due to the change from ParseStatement to ParseStatementListItem, this will result in slightly different error messages for lexical declarations in sloppy mode (until those are shipped). R=littledan@chromium.org, rossberg@chromium.org CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1433743005 Cr-Commit-Position: refs/heads/master@{#31966}
-
adamk authored
BUG=v8:2160 LOG=y Review URL: https://codereview.chromium.org/1438753002 Cr-Commit-Position: refs/heads/master@{#31965}
-
evan.lucas authored
Instead of basing matches off of whitespace, walk the inheritance chain and include any classes that inherit from Object. R=machenbach@chromium.org,jkummerow@chromium.org NOTRY=true Review URL: https://codereview.chromium.org/1435643002 Cr-Commit-Position: refs/heads/master@{#31964}
-
mbrandy authored
Remove hard-coded assumption of large object size threshold. This test fails on PPC in version 4.7 where the threshold is derived directly from the allocator's pagesize. R=hpayer@chromium.org, mstarzinger@chromium.org, michael_dawson@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1440723002 Cr-Commit-Position: refs/heads/master@{#31963}
-
jkummerow authored
BUG=v8:1543 LOG=n Review URL: https://codereview.chromium.org/1438233002 Cr-Commit-Position: refs/heads/master@{#31962}
-
fedor authored
BUG= R=machenbach Review URL: https://codereview.chromium.org/1439763002 Cr-Commit-Position: refs/heads/master@{#31961}
-
bmeurer authored
Now JSIntrinsicLowering can also lower %_IsSpecObject intrinsics to a diamond. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1436943005 Cr-Commit-Position: refs/heads/master@{#31960}
-
ishell authored
This CL fixes several sources of non-predictability by making Platform::MonotonicallyIncreasingTime() the only bottleneck for all time-querying functions and providing PredictablePlatform implementation. Review URL: https://codereview.chromium.org/1415383004 Cr-Commit-Position: refs/heads/master@{#31959}
-
bmeurer authored
Only inline one candidate per iteration to make sure we really inline the stuff that is called most often. R=mstarzinger@chromium.org BUG=v8:4493, v8:4544 LOG=n Review URL: https://codereview.chromium.org/1439773003 Cr-Commit-Position: refs/heads/master@{#31958}
-
bmeurer authored
This adds initial support for fast inline allocations of JSObject instances. It currently has exactly the same limitations as Crankshaft. R=mstarzinger@chromium.org BUG=v8:4544 LOG=n Review URL: https://codereview.chromium.org/1441573004 Cr-Commit-Position: refs/heads/master@{#31957}
-
yangguo authored
R=jkummerow@chromium.org BUG=chromium:523919 LOG=N Review URL: https://codereview.chromium.org/1440983002 Cr-Commit-Position: refs/heads/master@{#31956}
-
mstarzinger authored
This passes both, the actual constructor and the original constructor, to nodes having the {JSCreate} operator. This is required for allocating properly subclassed implicit receiver objects. R=verwaest@chromium.org BUG=v8:4544 LOG=n Review URL: https://codereview.chromium.org/1434873004 Cr-Commit-Position: refs/heads/master@{#31955}
-
mstarzinger authored
This implements a first version of support for constructor call inlining in the inlining machinery. For now we can only inline calls where the actual constructor and the original constructor coincide (i.e. no super constructor calls). Note that the target of a super constructor call is loaded with a runtime call, so there is no way for it to be constant promoted at the moment. R=bmeurer@chromium.org BUG=v8:4544 LOG=n Review URL: https://codereview.chromium.org/1435873002 Cr-Commit-Position: refs/heads/master@{#31954}
-
bmeurer authored
With subclassing and @@toStringTag, %_ClassOf is not necessarily what you want for ES6 anymore, so better avoid relying on %_ClassOf in our builtins. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1439003002 Cr-Commit-Position: refs/heads/master@{#31953}
-
v8-autoroll authored
Rolling v8/tools/clang to 0b258f75323161e854038f30334e97ab6aa58eab TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review URL: https://codereview.chromium.org/1440623005 Cr-Commit-Position: refs/heads/master@{#31952}
-
- 11 Nov, 2015 7 commits
-
-
bradnelson authored
The ~ operator is de-sugared into true^x, which was being improperly handled. Adding tests of most bitwise operators and several error cases. BUG= https://code.google.com/p/v8/issues/detail?id=4203 TEST=test-asm-validator R=titzer@chromium.org,aseemgarg@chromium.org LOG=N Review URL: https://codereview.chromium.org/1432423003 Cr-Commit-Position: refs/heads/master@{#31951}
-
mbrandy authored
R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, dstence@us.ibm.com BUG= Review URL: https://codereview.chromium.org/1440813002 Cr-Commit-Position: refs/heads/master@{#31950}
-
mbrandy authored
R=ahaas@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, dstence@us.ibm.com BUG= Review URL: https://codereview.chromium.org/1440733002 Cr-Commit-Position: refs/heads/master@{#31949}
-
ofrobots authored
Presently the inline allocation step is a static value defined to be the minimum of the step sizes over all the observers. The step occur every (approx.) step byte. This is unfair to observers whose steps are not evenly divisible by the min step size. For example, consider two observers with steps sizes of 512 and 576 bytes. Across 16kb allocated, you would expect the first observer to be hit approximately 32 times, and the second observer to be hit approximately 28 times. In reality, the observers get notified 30 and 15 times respectively. The reason is that each step is 512 bytes, and since 576 is not evenly divisible by 512, it gets notified much less frequently. This CL fixes the problem by making the next step size be the minimum (over all observers) of the remaining bytes to get to the step, making the steps fair. BUG= R=hpayer@chromium.org,ulan@chromium.org Review URL: https://codereview.chromium.org/1427973006 Cr-Commit-Position: refs/heads/master@{#31948}
-
fedor authored
I have discovered need in those values when writing: https://github.com/indutny/llnode BUG= Review URL: https://codereview.chromium.org/1436473002 Cr-Commit-Position: refs/heads/master@{#31947}
-
ahaas authored
I don't see obvious implementations for mips64 and ppc64, so I would need help for these two platforms. R=titzer@chromium.org Review URL: https://codereview.chromium.org/1436943002 Cr-Commit-Position: refs/heads/master@{#31946}
-
mbrandy authored
Check whether a trampoline pool should be emitted after unblocking. Otherwise, back-to-back sequences which block the trampoline pool can cause it to be out of reach. R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, dstence@us.ibm.com BUG= Review URL: https://codereview.chromium.org/1433343002 Cr-Commit-Position: refs/heads/master@{#31945}
-