- 26 Oct, 2016 7 commits
-
-
neis authored
Native setters (see AccessorInfo in accessors.h) didn't have the ability to return a result value. As a consequence of this, for instance, Reflect.set on the length property of arrays had the wrong behavior: var y = []; Object.defineProperty(y, 0, {value: 42, configurable: false}) Reflect.set(y, 'length', 0) The Reflect.set call used to return true. Now it returns false as required by the spec. BUG=v8:5401 Review-Url: https://codereview.chromium.org/2397603003 Cr-Commit-Position: refs/heads/master@{#40579}
-
bmeurer authored
For global object property cells, we did not check that the map on the previous object is still the same for which we actually optimized. So the optimized code was not in sync with the actual state of the property cell. When loading from such a global object property cell, Crankshaft optimizes away any map checks (based on the stable map assumption), leading to arbitrary memory access in the worst case. TurboFan has the same bug for stores, but is safe on loads because we do appropriate map checks there. However mixing TurboFan and Crankshaft still exposes the bug. R=yangguo@chromium.org BUG=chromium:659475 Review-Url: https://codereview.chromium.org/2444233004 Cr-Commit-Position: refs/heads/master@{#40578}
-
bmeurer authored
The meaning of the HValue::kAllowUndefinedAsNaN is actually ToNumber conversion (except for the uses in HBranch and HCompareHoleAndBranch, which were confusing and useless anyways), so fix the naming to match that. Also properly integrate the handling of this flag with the existing truncation analysis that is run as part of the representation changes phase (i.e. where we already deal with truncating to int32 and smi). This is done in preparation of allowing Crankshaft to handle any kind of Oddball in the ToNumber truncation, instead of just undefined for truncation ToNumber and undefined or boolean for ToInt32. It also helps to make Crankshaft somewhat more compatible with the (saner) implementation in TurboFan. R=yangguo@chromium.org BUG=v8:5400 Review-Url: https://codereview.chromium.org/2449353002 Cr-Commit-Position: refs/heads/master@{#40577}
-
cbruni authored
Fix failing assertions in the CodeStubAssembler that cause Object.create(null, global) fail. Drive-by-fix: convert some Assert to CSA_ASSERT. BUG=chromium:657692 Review-Url: https://codereview.chromium.org/2446203003 Cr-Commit-Position: refs/heads/master@{#40576}
-
cbruni authored
All uses of NeanderObject have been replaced by FixedArrays. BUG= Review-Url: https://codereview.chromium.org/2447123002 Cr-Commit-Position: refs/heads/master@{#40575}
-
cbruni authored
A GC might cause the just created dictionary object to have an invalid backing store, which breaks heap verification. BUG=chromium:659088 Review-Url: https://codereview.chromium.org/2452653002 Cr-Commit-Position: refs/heads/master@{#40574}
-
bmeurer authored
For Math builtins that likely yield double results, i.e. Math.sin, Math.cos and friends, don't bother trying to canonicalize the result to Smi. The rationale behind this is that other parts of V8 use the HeapNumber representation as a hint to assume that certain values should be represented as double (i.e. for the array elements kind and for double field tracking). This way the chance that we make the ideal decision early on is better. For Math.abs we establish the contract that if the input value is a Smi, then we try hard to return a Smi (doesn't work for minimal Smi value), otherwise we preserve the HeapNumberness of the input. Same for the generic Add, Subtract, Multiply, etc. code stubs. R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2451973003 Cr-Commit-Position: refs/heads/master@{#40573}
-
- 25 Oct, 2016 29 commits
-
-
aseemgarg authored
BUG=chromium:658426 R=ahaas@chromium.org,titzer@chromium.org,gdeepti@chromium.org Review-Url: https://codereview.chromium.org/2447683004 Cr-Commit-Position: refs/heads/master@{#40572}
-
mtrofin authored
Simple "Print" API for the compiler graph. BUG= Review-Url: https://codereview.chromium.org/2447993002 Cr-Commit-Position: refs/heads/master@{#40571}
-
gsathya authored
This causes a 3.1% regression because we unconditionally call out to a runtime function. This patch refactors out most of EnqueuePromiseReactionJob runtime function into a separate function. BUG=v8:5343 Review-Url: https://codereview.chromium.org/2449053003 Cr-Commit-Position: refs/heads/master@{#40570}
-
ulan authored
This reverts commit 59fb0956. BUG=chromium:658718 Review-Url: https://codereview.chromium.org/2445283003 Cr-Commit-Position: refs/heads/master@{#40569}
-
georgia.kouveli authored
Emit the compare and branch on zero (CBZ) instruction when possible for deoptimisations, as we do for normal branches. BUG= Review-Url: https://codereview.chromium.org/2448113002 Cr-Commit-Position: refs/heads/master@{#40568}
-
ivica.bogosavljevic authored
Port dc6b5109 BUG= Review-Url: https://codereview.chromium.org/2437593006 Cr-Commit-Position: refs/heads/master@{#40567}
-
neis authored
Setting variables is not yet implemented. R=adamk@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2445683002 Cr-Commit-Position: refs/heads/master@{#40566}
-
ishell authored
BUG=v8:5561 Review-Url: https://codereview.chromium.org/2446983002 Cr-Commit-Position: refs/heads/master@{#40565}
-
machenbach authored
Revert of [modules] Add partial support for debug-scopes. (patchset #1 id:1 of https://codereview.chromium.org/2445683002/ ) Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/9349 Original issue's description: > [modules] Add partial support for debug-scopes. > > Setting variables is not yet implemented.. > > R=adamk@chromium.org > BUG=v8:1569 TBR=adamk@chromium.org,yangguo@chromium.org,neis@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:1569 Review-Url: https://codereview.chromium.org/2449883002 Cr-Commit-Position: refs/heads/master@{#40564}
-
leszeks authored
This lets us investigate regressions caused by this marking while letting others continue their work without being impacted. BUG=v8:5512 Review-Url: https://codereview.chromium.org/2446673002 Cr-Commit-Position: refs/heads/master@{#40563}
-
gsathya authored
Removes PromiseEnqueue and moves debugging code to a separate function which gets called when the debugger is active. BUG=v8:5343 Review-Url: https://codereview.chromium.org/2450763002 Cr-Commit-Position: refs/heads/master@{#40562}
-
verwaest authored
BUG= Review-Url: https://codereview.chromium.org/2446993002 Cr-Commit-Position: refs/heads/master@{#40561}
-
jochen authored
BUG=v8:5557 R=cbruni@chromium.org Review-Url: https://codereview.chromium.org/2448473002 Cr-Commit-Position: refs/heads/master@{#40560}
-
neis authored
Setting variables is not yet implemented.. R=adamk@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2445683002 Cr-Commit-Position: refs/heads/master@{#40559}
-
mstarzinger authored
This is a partial revert of 438c5eb2 to avoid huge increases in testing times due to expensive bytecode handler generation in debug modes. The additional coverage does not warrant a 2x to 3x increase in testing time at the moment. We can revisit this later. TBR=rmcilroy@chromium.org NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2445403002 Cr-Commit-Position: refs/heads/master@{#40558}
-
adamk authored
This brings the BytecodeGenerator in line with FullCodeGenerator, now that more requests for hole checks are flowing through BuildVariableAssignment. BUG=chromium:658528 Review-Url: https://codereview.chromium.org/2447783002 Cr-Commit-Position: refs/heads/master@{#40557}
-
gsathya authored
FulfillPromise is always called when a promise is in a pending state which makes this check redundant. Review-Url: https://codereview.chromium.org/2442373002 Cr-Commit-Position: refs/heads/master@{#40556}
-
mstarzinger authored
This makes sure that bytecode handlers are regenerated when debugging code within handlers is being requested. We cannot use the handlers baked into the snapshot in this case. R=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2443923002 Cr-Commit-Position: refs/heads/master@{#40555}
-
titzer authored
R=bradnelson@chromium.org, rossberg@chromium.org BUG=v8:5507 Review-Url: https://codereview.chromium.org/2443353002 Cr-Commit-Position: refs/heads/master@{#40554}
-
clemensh authored
And add a test case for more than one entry ;) R=titzer@chromium.org,ahaas@chromium.org Review-Url: https://codereview.chromium.org/2448833004 Cr-Commit-Position: refs/heads/master@{#40553}
-
clemensh authored
The function name table is not used any more since https://chromiumcodereview.appspot.com/2424623002, so remove it. R=titzer@chromium.org,ahaas@chromium.org Review-Url: https://codereview.chromium.org/2451693002 Cr-Commit-Position: refs/heads/master@{#40552}
-
cbruni authored
Object.create(null) is most likely to be used for dictionary-like objects. Hence it would be beneficial to directly create a slow-mode object and avoid additional overhead later-on. BUG= Review-Url: https://codereview.chromium.org/2430273007 Cr-Commit-Position: refs/heads/master@{#40551}
-
bmeurer authored
The interpreter is currently too aggressive in tiering up to TurboFan, especially for (expensive) OSR. Make it slightly less aggressive by choosing a more realistic code size multiplier. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2448043002 Cr-Commit-Position: refs/heads/master@{#40550}
-
yangguo authored
R=jgruber@chromium.org BUG=v8:5559 Review-Url: https://codereview.chromium.org/2445233004 Cr-Commit-Position: refs/heads/master@{#40549}
-
verwaest authored
BUG= Review-Url: https://codereview.chromium.org/2445993002 Cr-Commit-Position: refs/heads/master@{#40548}
-
jgruber authored
This CL removes code that is now unused since the port of regexp.js has been completed. Removed functions / classes are: * regexp.js (GetSubstitution moved to string.js) * RegExpConstructResult stub * RegExpFlags intrinsic * RegExpSource intrinsic * RegExpInitializeAndCompile runtime function BUG=v8:5339 Review-Url: https://codereview.chromium.org/2448463002 Cr-Commit-Position: refs/heads/master@{#40547}
-
kozyatinskiy authored
To achieve this: - fixed crash on windows - String16::fromInteger used "%zu" which doesn't support by VS2013 compiler, wrapped with ifdef else. - fixed asan for d8 - unique_ptr on array has single element type. - force Debugger.disable at the end of test. BUG=chromium:635948 R=dgozman@chromium.org,yangguo@chromium.org,machenbach@chromium.org Review-Url: https://codereview.chromium.org/2450653002 Cr-Commit-Position: refs/heads/master@{#40546}
-
jgruber authored
BUG=v8:5339 Review-Url: https://codereview.chromium.org/2442333002 Cr-Commit-Position: refs/heads/master@{#40545}
-
bmeurer authored
Don't inline the full StringFromCharCode logic into TurboFan, but only the common case, and use the %StringFromCharCode runtime function for the rest, similar to what we do in HStringCharFromCode in Crankshaft. This greatly reduces compile time for TurboFan due to greatly reduced number of nodes. For example it reduces overall runtime of the base64 benchmark by up to 15% with the future pipeline. R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2445273002 Cr-Commit-Position: refs/heads/master@{#40544}
-
- 24 Oct, 2016 4 commits
-
-
rmcilroy authored
Modify the Bytecode Register Optimizer to be an independent component rather than part of the BytecodePipeline. This means the BytecodeArrayBuilder can explicitly call it with register operands when outputting a bytecode and the Bytecode Register Optimizer doesn't need to work out which operands are register operands. This also means we don't need to build BytecodeNodes for Ldar / Star / Mov bytecodes unless they are actually emitted by the optimizer. This change also modifies the way the BytecodeArrayBuilder converts operands to make use of the OperandTypes specified in bytecodes.h. This avoids having to individually convert operands to their raw output value before calling Output(...). BUG=v8:4280 Review-Url: https://codereview.chromium.org/2393683004 Cr-Commit-Position: refs/heads/master@{#40543}
-
verwaest authored
Now we - always set .result to undefined before a visited loop and switch since we can't know whether they will set a value, - only visit finally if it can break/continue; and only store/restore .result in that case BUG= Review-Url: https://codereview.chromium.org/2427253003 Cr-Commit-Position: refs/heads/master@{#40542}
-
rmcilroy authored
CL https://codereview.chromium.org/2177273002 changed FastNewFunctionContextStub to take a number of slots parameter and in-doing so removed the maximum slot count for FastNewFunctionContextStub. This made it possible to create a closure which is larger than kMaxRegularHeapObjectSize and so can't be allocated by FastNewFunctionContextStub. Reintroduce FastNewFunctionContextStub::kMaxSlots (but make the limit much larger) to ensure we call the runtime for contexts which need to be allocated in the LO space. BUG=chromium:655573 Review-Url: https://codereview.chromium.org/2445703002 Cr-Commit-Position: refs/heads/master@{#40541}
-
marja authored
R=jochen@chromium.org BUG=chromium:656854 Review-Url: https://codereview.chromium.org/2427933002 Cr-Commit-Position: refs/heads/master@{#40540}
-