- 28 Feb, 2016 2 commits
-
-
hablich authored
TBR=machenbach@chromium.org NOTRY=true Review URL: https://codereview.chromium.org/1744823002 Cr-Commit-Position: refs/heads/master@{#34347}
-
titzer authored
R=binji@chromium.org,jfb@chromium.org BUG= Review URL: https://codereview.chromium.org/1740373002 Cr-Commit-Position: refs/heads/master@{#34346}
-
- 27 Feb, 2016 4 commits
-
-
titzer authored
R=bradnelson@chromium.org,aseemgarg@chromium.org BUG= Review URL: https://codereview.chromium.org/1742073002 Cr-Commit-Position: refs/heads/master@{#34345}
-
bmeurer authored
Since both null and undefined are also marked as undetectable now, we can just test that bit instead of having the CompareNilIC try to collect feedback to speed up the general case (without the undetectable bit being used). Drive-by-fix: Update the type system to match the new handling of undetectable in the runtime. R=danno@chromium.org Committed: https://crrev.com/666aec0348c8793e61c8633dee7ad29a514239ba Cr-Commit-Position: refs/heads/master@{#34237} Review URL: https://codereview.chromium.org/1722193002 Cr-Commit-Position: refs/heads/master@{#34344}
-
v8-autoroll authored
Rolling v8/tools/clang to e67c4fe288f02e1d208961b757ff78d5b3e51782 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review URL: https://codereview.chromium.org/1744783002 Cr-Commit-Position: refs/heads/master@{#34343}
-
titzer authored
R=binji@chromium.org,jfb@chromium.org BUG= Review URL: https://codereview.chromium.org/1744713003 Cr-Commit-Position: refs/heads/master@{#34342}
-
- 26 Feb, 2016 34 commits
-
-
mbrandy authored
Port d00da47b Original commit message: The CompareICStub produces an untagged raw word value, which has to be translated to true or false manually in the TurboFan code. But for lazy bailout after the CompareIC, we immediately go back to fullcodegen or Ignition with the raw value, to a location where both fullcodegen and Ignition expect a boolean value, which might crash or in the worst case (depending on the exact computation inside the CompareIC) could lead to arbitrary memory access. Short-term fix is to use the proper runtime functions (unified with the interpreter now) for comparisons. Next task is to provide optimized versions of these based on the CodeStubAssembler, which can then be used via code stubs in TurboFan or directly in handlers in the interpreter. R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:4788 LOG=n Review URL: https://codereview.chromium.org/1745643002 Cr-Commit-Position: refs/heads/master@{#34341}
-
mbrandy authored
Revert of PPC: [compiler] Drop the CompareNilIC. (patchset #1 id:1 of https://codereview.chromium.org/1733663003/ ) Reason for revert: Original commit reverted. Original issue's description: > PPC: [compiler] Drop the CompareNilIC. > > Port 666aec03 > > Original commit message: > Since both null and undefined are also marked as undetectable now, we > can just test that bit instead of having the CompareNilIC try to collect > feedback to speed up the general case (without the undetectable bit > being used). > > Drive-by-fix: Update the type system to match the new handling of > undetectable in the runtime. > > R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com > BUG= > > Committed: https://crrev.com/546ea6b8393a894f07597ade5ec1c7db02c1e425 > Cr-Commit-Position: refs/heads/master@{#34266} TBR=bmeurer@chromium.org,joransiu@ca.ibm.com,jyan@ca.ibm.com,michael_dawson@ca.ibm.com # Not skipping CQ checks because original CL landed more than 1 days ago. BUG= Review URL: https://codereview.chromium.org/1736253003 Cr-Commit-Position: refs/heads/master@{#34340}
-
littledan authored
ES2015 allows strict mode block scoped function declarations; weaken the error message about misuse to allow this. BUG=v8:2198 LOG=Y R=adamk Review URL: https://codereview.chromium.org/1741903002 Cr-Commit-Position: refs/heads/master@{#34339}
-
littledan authored
Reland of Test262 roll, 2016-2-23 (patchset #1 id:1 of https://codereview.chromium.org/1736223002/ ) Reason for revert: Intl change relanded https://codereview.chromium.org/1745483002/ Original issue's description: > Revert of Test262 roll, 2016-2-23 (patchset #2 id:20001 of https://codereview.chromium.org/1738033002/ ) > > Reason for revert: > An Intl change that this depends on breaks a bot > > Original issue's description: > > Test262 roll, 2016-2-23 > > > > R=adamk > > > > Committed: https://crrev.com/34492040fbfb04fead21416245c8696b9847e751 > > Cr-Commit-Position: refs/heads/master@{#34312} > > TBR=adamk@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > > Committed: https://crrev.com/3b829ad80628bf521aa78255c2e5e20040a57b5f > Cr-Commit-Position: refs/heads/master@{#34313} TBR=adamk@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1739533006 Cr-Commit-Position: refs/heads/master@{#34338}
-
littledan authored
Reland of Make Intl install properties more like how other builtins do (patchset #1 id:1 of https://codereview.chromium.org/1733293003/ ) This reland fixes a bug by pulling properties off the utils object, so that it can be garbage collected in nosnap builds. Original commit message: Intl has been somewhat of an oddball for how it integrates with V8. One aspect is that it largely didn't use utils to install itself into the snapshot, which led to some missing names, which new test262 tests check for, and duplicated code. This patch brings Intl a bit closer to how the rest of the builtins do things, though not entirely as it is currently structured to do unusual things, such as creating new constructors from JavaScript rather than C++. New test262 tests check for some of the names that are added in this patch. R=adamk CC=jshin BUG=v8:4778 LOG=Y Review URL: https://codereview.chromium.org/1745483002 Cr-Commit-Position: refs/heads/master@{#34337}
-
alan.li authored
Port 3ef573e9 Original commit message: Replace the somewhat awkward RestParamAccessStub, which would always call into the runtime anyway with a proper FastNewRestParameterStub, which is basically based on the code that was already there for strict arguments object materialization. But for rest parameters we could optimize even further (leading to 8-10x improvements for functions with rest parameters), by fixing the internal formal parameter count: Every SharedFunctionInfo has a formal_parameter_count field, which specifies the number of formal parameters, and is used to decide whether we need to create an arguments adaptor frame when calling a function (i.e. if there's a mismatch between the actual and expected parameters). Previously the formal_parameter_count included the rest parameter, which was sort of unfortunate, as that meant that calling a function with only the non-rest parameters still required an arguments adaptor (plus some other oddities). Now with this CL we fix, so that we do no longer include the rest parameter in that count. Thereby checking for rest parameters is very efficient, as we only need to check whether there is an arguments adaptor frame, and if not create an empty array, otherwise check whether the arguments adaptor frame has more parameters than specified by the formal_parameter_count. The FastNewRestParameterStub is written in a way that it can be directly used by Ignition as well, and with some tweaks to the TurboFan backends and the CodeStubAssembler, we should be able to rewrite it as TurboFanCodeStub in the near future. Drive-by-fix: Refactor and unify the CreateArgumentsType which was different in TurboFan and Ignition; now we have a single enum class which is used in both TurboFan and Ignition. TEST=test/mjsunit/harmony/destructuring, test/mjsunit/harmony/default-parameters, test/mjsunit/harmony/default-parameters, test/mjsunit/es6/classes-subclass-builtins, BUG= Review URL: https://codereview.chromium.org/1734273003 Cr-Commit-Position: refs/heads/master@{#34336}
-
bmeurer authored
The CompareICStub produces an untagged raw word value, which has to be translated to true or false manually in the TurboFan code. But for lazy bailout after the CompareIC, we immediately go back to fullcodegen or Ignition with the raw value, to a location where both fullcodegen and Ignition expect a boolean value, which might crash or in the worst case (depending on the exact computation inside the CompareIC) could lead to arbitrary memory access. Short-term fix is to use the proper runtime functions (unified with the interpreter now) for comparisons. Next task is to provide optimized versions of these based on the CodeStubAssembler, which can then be used via code stubs in TurboFan or directly in handlers in the interpreter. R=mstarzinger@chromium.org BUG=v8:4788 LOG=n Review URL: https://codereview.chromium.org/1738153002 Cr-Commit-Position: refs/heads/master@{#34335}
-
rmcilroy authored
Moves skips to explicit fails and groups errors be failure reason. Almost all failures are due to lack of generator support. BUG=v8:4680 LOG=N TBR=oth@chromium.org Review URL: https://codereview.chromium.org/1740843003 Cr-Commit-Position: refs/heads/master@{#34334}
-
mstarzinger authored
R=bmeurer@chromium.org BUG=v8:3956 LOG=n Review URL: https://codereview.chromium.org/1734243004 Cr-Commit-Position: refs/heads/master@{#34333}
-
fmeawad authored
This patch adds the newly added support for contexts in V8 Tracing, as well as use it to mark all the entry points for a V8 Isolate. Update for reland: The current tracing interface needs to be updated (AddTraceEvent), but the embedders need to migrate to the new version before removing the old version. (Reland of: https://codereview.chromium.org/1686233002) The revert happened because the 2 signatures of the old and new AddTraceEvent where different so it threw an overload-virtual error on cross arm debug. This issue is temporary, and to solve it, I added an implementation of the old and new everywhere until the embedder implements the new. BUG=v8:4565 LOG=N R=jochen@chromium.org Review URL: https://codereview.chromium.org/1704253002 Cr-Commit-Position: refs/heads/master@{#34332}
-
joransiu authored
Initial commit with the bulk of the src/s390/* changes along with associated changes to the build toolchain for the new files. A minor update to V8PRIuPTR definition for Mac OS X affecting 32-bit S390 sim compilations. R=danno@chromium.org,jkummerow@chromium.org,jochen@chromium.org,jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com BUG= Review URL: https://codereview.chromium.org/1725243004 Cr-Commit-Position: refs/heads/master@{#34331}
-
alan.li authored
Port ba2077aa Original commit message: Move the already existing fast case for %NewObject into a dedicated FastNewObjectStub that we can utilize in places where we would otherwise fallback to %NewObject immediately, which is rather expensive. Also use FastNewObjectStub as the generic implementation of JSCreate, which should make constructor inlining based on SharedFunctionInfo (w/o specializing to a concrete closure) viable soon. BUG= Review URL: https://codereview.chromium.org/1732333002 Cr-Commit-Position: refs/heads/master@{#34330}
-
rmcilroy authored
Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/. TBR=adamk@chromium.org BUG=v8:3566,v8:4280 LOG=N Review URL: https://codereview.chromium.org/1738143002 Cr-Commit-Position: refs/heads/master@{#34329}
-
mstarzinger authored
This fixes the length computation in for object literals in generic lowering. In rare cases (e.g. boilerplate at end of page) this could lead to out of bounds reads. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1737893003 Cr-Commit-Position: refs/heads/master@{#34328}
-
jochen authored
We know it's a postive integer BUG= R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1739753004 Cr-Commit-Position: refs/heads/master@{#34327}
-
jochen authored
BUG= R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1743543002 Cr-Commit-Position: refs/heads/master@{#34326}
-
jochen authored
The keys are always positive integers, so use an UnseededNumberDictionary to store them instead of an ObjectHashTable R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1741623003 Cr-Commit-Position: refs/heads/master@{#34325}
-
ssanfilippo authored
When operating in --rebaseline mode, each of the files will be updated. In --raw-js mode, all the expectations will be written to the same file. In default mode no more than one input file is accepted. On POSIX systems, --rebaseline will autodiscover golden files when run from the project root and no input file is provided. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1737623002 Cr-Commit-Position: refs/heads/master@{#34324}
-
bmeurer authored
R=mstarzinger@chromium.org BUG=v8:4768 LOG=n Review URL: https://codereview.chromium.org/1737273003 Cr-Commit-Position: refs/heads/master@{#34323}
-
bmeurer authored
The LoadBuffer operator that is used for asm.js heap access claims to return only the appropriate typed array type, but out of bounds access could make it return undefined. So far we tried to "repair" the graph later if we see that our assumption was wrong, and for various reasons that worked for some time. But now that wrong type information that is propagated earlier is picked up appropriately and thus we generate wrong code, i.e. we in the repro case we feed NaN into ChangeFloat64Uint32 and thus get 2147483648 instead of 0 (with proper JS truncation). This was always considered a temporary hack until we have a proper asm.js pipeline, but since we still run asm.js through the generic JavaScript pipeline, we have to address this now. Quickfix is to just bailout from the pipeline when we see that the LoadBuffer type was wrong, i.e. the result of LoadBuffer is not properly truncated and thus undefined or NaN would be observable. R=mstarzinger@chromium.org, jarin@chromium.org BUG=chromium:589792 LOG=y Review URL: https://codereview.chromium.org/1740123002 Cr-Commit-Position: refs/heads/master@{#34322}
-
rmcilroy authored
Adds support for cpu profiler logging to the interpreter. Modifies the the API to be passed AbstractCode objects instead of Code objects, and adds extra functions to AbstractCode which is required by log.cc and cpu-profiler.cc. The main change in sampler.cc is to determine if a stack frame is an interpreter stack frame, and if so, use the bytecode address as the pc for that frame. This allows sampling of bytecode functions. This requires adding support to SafeStackIterator to determine if a frame is interpreted, which we do by checking the PC against pre-stored addresses for the start and end of interpreter entry builtins. Also removes CodeDeleteEvents which are dead code and haven't been reported for some time. Still to do is tracking source positions which will be done in a followup CL. BUG=v8:4766 LOG=N Review URL: https://codereview.chromium.org/1728593002 Cr-Commit-Position: refs/heads/master@{#34321}
-
ishell authored
Everything that HCallJSFunction does can be easily done using more general HInvokeFunction, so there's no need to have this dedicated instruction around. Review URL: https://codereview.chromium.org/1728423002 Cr-Commit-Position: refs/heads/master@{#34320}
-
oth authored
Extends the constant pool to deal with more slices. Adds ReadUnalignedUInt32(). BUG=v8:4280,v8:4747 LOG=N Review URL: https://codereview.chromium.org/1731893003 Cr-Commit-Position: refs/heads/master@{#34319}
-
bmeurer authored
We don't need to compare the result of ToObject against null, since ToObject will always yield a proper receiver (or throw a TypeError). R=rmcilroy@chromium.org Review URL: https://codereview.chromium.org/1736233002 Cr-Commit-Position: refs/heads/master@{#34318}
-
bmeurer authored
The %TailCall runtime entry and the %_TailCall intrinsic is not used, and will never be used (because %TailCall doesn't actually do a tail call). We will soon have proper ES6 tail calls, which are correct and properly tested. The %Apply runtime entry is basically a super-slow, less correct version of Reflect.apply, so we can as well just use Reflect.apply, which is exposed to builtins via %reflect_apply. R=ishell@chromium.org Review URL: https://codereview.chromium.org/1739233002 Cr-Commit-Position: refs/heads/master@{#34317}
-
bmeurer authored
The %_Call intrinsic (if supported by the compiler) is lowered directly to the Call builtin and thus throws a TypeError if the target is not callable. The %Call runtime function also eventually calls into the Call builtin, but had an early abort if the target is not a JSReceiver, which is unnecessary and leads to various test failures for Ignition. R=mvstanton@chromium.org Review URL: https://codereview.chromium.org/1727833006 Cr-Commit-Position: refs/heads/master@{#34316}
-
bmeurer authored
The treatment of different undetectable objects was inconsistent after the latest changes to the undetectable bit in the maps. Given two different undetectable JSObjects a and b, a monomorphic CompareIC would say false for a == b, while the rest of the system (including the generic case for the CompareIC) would say true. The fix is rather straight-forward: We just go generic on a CompareIC once we see an undetectable JSObject. R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1735863004 Cr-Commit-Position: refs/heads/master@{#34315}
-
littledan authored
Revert of Make Intl install properties more like how other builtins do (patchset #1 id:1 of https://codereview.chromium.org/1733293003/ ) Reason for revert: Breaks a bot: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap/builds/6812 Original issue's description: > Make Intl install properties more like how other builtins do > > Intl has been somewhat of an oddball for how it integrates with V8. > One aspect is that it largely didn't use utils to install itself > into the snapshot, which led to some missing names, which new > test262 tests check for, and duplicated code. This patch brings > Intl a bit closer to how the rest of the builtins do things, though > not entirely as it is currently structured to do unusual things, > such as creating new constructors from JavaScript rather than C++. > New test262 tests check for some of the names that are added in > this patch. > > R=adamk > CC=jshin > BUG=v8:4778 > LOG=Y > > Committed: https://crrev.com/a40830577d80f699282dd83864619656b7a7966c > Cr-Commit-Position: refs/heads/master@{#34311} TBR=adamk@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4778 Review URL: https://codereview.chromium.org/1737873003 Cr-Commit-Position: refs/heads/master@{#34314}
-
littledan authored
Revert of Test262 roll, 2016-2-23 (patchset #2 id:20001 of https://codereview.chromium.org/1738033002/ ) Reason for revert: An Intl change that this depends on breaks a bot Original issue's description: > Test262 roll, 2016-2-23 > > R=adamk > > Committed: https://crrev.com/34492040fbfb04fead21416245c8696b9847e751 > Cr-Commit-Position: refs/heads/master@{#34312} TBR=adamk@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1736223002 Cr-Commit-Position: refs/heads/master@{#34313}
-
littledan authored
R=adamk Review URL: https://codereview.chromium.org/1738033002 Cr-Commit-Position: refs/heads/master@{#34312}
-
littledan authored
Intl has been somewhat of an oddball for how it integrates with V8. One aspect is that it largely didn't use utils to install itself into the snapshot, which led to some missing names, which new test262 tests check for, and duplicated code. This patch brings Intl a bit closer to how the rest of the builtins do things, though not entirely as it is currently structured to do unusual things, such as creating new constructors from JavaScript rather than C++. New test262 tests check for some of the names that are added in this patch. R=adamk CC=jshin BUG=v8:4778 LOG=Y Review URL: https://codereview.chromium.org/1733293003 Cr-Commit-Position: refs/heads/master@{#34311}
-
littledan authored
BUG=v8:4315 R=adamk LOG=Y Review URL: https://codereview.chromium.org/1734223004 Cr-Commit-Position: refs/heads/master@{#34310}
-
v8-autoroll authored
Rolling v8/base/trace_event/common to 81b7b6f531ad2375140b2a5f4d3a803e5ba2514c Rolling v8/buildtools to 14288a03a92856fe1fc296d39e6a25c2d83cd6cf Rolling v8/tools/swarming_client to a72f46e42dba1335e8001499b4621acad2d26728 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review URL: https://codereview.chromium.org/1737243003 Cr-Commit-Position: refs/heads/master@{#34309}
-
adamk authored
Revert of [compiler] Drop the CompareNilIC. (patchset #4 id:60001 of https://codereview.chromium.org/1722193002/ ) Reason for revert: Speculative revert in attempt to fix #2 crasher on canary. Original issue's description: > [compiler] Drop the CompareNilIC. > > Since both null and undefined are also marked as undetectable now, we > can just test that bit instead of having the CompareNilIC try to collect > feedback to speed up the general case (without the undetectable bit > being used). > > Drive-by-fix: Update the type system to match the new handling of > undetectable in the runtime. > > R=danno@chromium.org > > Committed: https://crrev.com/666aec0348c8793e61c8633dee7ad29a514239ba > Cr-Commit-Position: refs/heads/master@{#34237} TBR=danno@chromium.org,verwaest@chromium.org,bmeurer@chromium.org LOG=y BUG=chromium:589897 NOTRY=true Review URL: https://codereview.chromium.org/1743433002 Cr-Commit-Position: refs/heads/master@{#34308}
-