- 28 Oct, 2016 4 commits
-
-
jgruber authored
This adds a wrapper class around the inspector protocol for use in debugger tests. The interface is intended to stay similar to the currently exposed DebuggerContext. Right now, we support adding a listener, (partial) handling of the AfterCompile event, and enabling/disabling the debugger. BUG=v8:5530 Review-Url: https://codereview.chromium.org/2451153003 Cr-Commit-Position: refs/heads/master@{#40635}
-
jgruber authored
BUG=v8:5339 Review-Url: https://codereview.chromium.org/2452923002 Cr-Commit-Position: refs/heads/master@{#40634}
-
clemensh authored
In the asm.js to wasm pipeline, we generate an entry function with BUILTIN code, but still attached to a TYPE_NORMAL script. This fix avoids trying to set a breakpoint there, resulting in a crash on DCHECK(shared->HasDebugInfo()). Also add two inspector tests to track regressions. BUG=v8:5568 R=titzer@chromium.org,mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2457433002 Cr-Commit-Position: refs/heads/master@{#40633}
-
zhengxing.li authored
port 7d383be9 (r40608) original commit message: For inputs to truncating binary operations like <<, | or >>>, support all Oddballs not just undefined, true and false. This unifies treatment of these truncations in Crankshaft and TurboFan, and is very easy nowadays, since the memory layout of Oddball and HeapNumber is compatible. BUG= Review-Url: https://codereview.chromium.org/2450093007 Cr-Commit-Position: refs/heads/master@{#40632}
-
- 27 Oct, 2016 25 commits
-
-
bjaideep authored
Converting INT_MIN to positive should cause overflow, which was not being captured. Fixed the logic to detect if value is equal to INT_MIN and set the overflow code accordingly. R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com BUG= LOG=N Review-Url: https://codereview.chromium.org/2446113013 Cr-Commit-Position: refs/heads/master@{#40631}
-
yangguo authored
The first 32 root list items are a conscious choice in order for the serializer to encode root references more efficiently. R=hpayer@chromium.org Review-Url: https://codereview.chromium.org/2458603002 Cr-Commit-Position: refs/heads/master@{#40630}
-
ulan authored
BUG=chromium:659165 Review-Url: https://codereview.chromium.org/2455103002 Cr-Commit-Position: refs/heads/master@{#40629}
-
ahaas authored
This change makes the embenchen/copy benchmark a factor of 2 faster and brings back the performance loss through graph trimming. R=titzer@chromium.org CC=bradnelson@chromium.org Review-Url: https://codereview.chromium.org/2453343002 Cr-Commit-Position: refs/heads/master@{#40628}
-
ishell authored
The reasons are: 1) Type feedback vectors are not shared between different native contexts and therefore the IC handler created for one native context will not be reused in other native context. 2) Access rights revocation is not supported at all, therefore given (1) once we pass the access check we don't have to check access rights again. BUG=v8:5561 Review-Url: https://codereview.chromium.org/2455953002 Cr-Commit-Position: refs/heads/master@{#40627}
-
ishell authored
BUG=v8:5561 Review-Url: https://codereview.chromium.org/2449463002 Cr-Commit-Position: refs/heads/master@{#40626}
-
bjaideep authored
Port 7d383be9 Original commit message: For inputs to truncating binary operations like <<, | or >>>, support all Oddballs not just undefined, true and false. This unifies treatment of these truncations in Crankshaft and TurboFan, and is very easy nowadays, since the memory layout of Oddball and HeapNumber is compatible. R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com BUG= LOG=N Review-Url: https://codereview.chromium.org/2455993002 Cr-Commit-Position: refs/heads/master@{#40625}
-
mstarzinger authored
The assumptions that OSR code is installed on {JSFunction} objects no longer holds with TurboFan and hence {assertOptimized} can report a different result dependeing on how OSR code is treated. This is working as intended. R=mythria@chromium.org Review-Url: https://codereview.chromium.org/2453313002 Cr-Commit-Position: refs/heads/master@{#40624}
-
yangguo authored
See https://goo.gl/C9U1dL BUG=chromium:617892 Review-Url: https://codereview.chromium.org/2452333002 Cr-Commit-Position: refs/heads/master@{#40623}
-
gsathya authored
This is no longer used. BUG=v8:5343 Review-Url: https://codereview.chromium.org/2454713003 Cr-Commit-Position: refs/heads/master@{#40622}
-
adamk authored
Unlike other variable allocation logic, MODULE allocation does not depend on resolution. So in order to give hole check elimination (which runs during resolution) access to the information "is this variable an import", simply allocate all modules variables prior to resolution. BUG=v8:1569 Review-Url: https://codereview.chromium.org/2458653002 Cr-Commit-Position: refs/heads/master@{#40621}
-
henrique.ferreiro authored
The latter was left from a previous commit and not updated later to reflect the new name. Review-Url: https://codereview.chromium.org/2447023004 Cr-Commit-Position: refs/heads/master@{#40620}
-
jarin authored
BUG=v8:5573 Review-Url: https://codereview.chromium.org/2458623002 Cr-Commit-Position: refs/heads/master@{#40619}
-
gsathya authored
This patch moves promise specific runtime functions to runtime-promise.cc from runtime-internal.cc BUG=v8:5343 Review-Url: https://codereview.chromium.org/2452833003 Cr-Commit-Position: refs/heads/master@{#40618}
-
mstarzinger authored
This prepares the code-base so that Ignition can be enabled on a certain subset of compilations without setting the {FLAG_ignition} flag (which enables Ignition on all compilations). We should not check the flag in question explicitly anywhere outside of the compiler heuristics. R=mvstanton@chromium.org Review-Url: https://codereview.chromium.org/2443573002 Cr-Commit-Position: refs/heads/master@{#40617}
-
bmeurer authored
R=jarin@chromium.org BUG=chromium:659967 Review-Url: https://codereview.chromium.org/2453633005 Cr-Commit-Position: refs/heads/master@{#40616}
-
gsathya authored
This patch refactors most of FulfillPromise runtime call out to a separate function so that we can to it from PromiseReject runtime call. This patch adds a PromiseStatus enum. BUG=v8:5343 Review-Url: https://codereview.chromium.org/2451163003 Cr-Commit-Position: refs/heads/master@{#40615}
-
ulan authored
This reverts commit 35e4a03f. BUG= Review-Url: https://codereview.chromium.org/2454723002 Cr-Commit-Position: refs/heads/master@{#40614}
-
neis authored
We used to point elsewhere, for instance the right-hand-side of an assignment. Small limitation: Since variable proxies only have a start position, not an end position, the best we can do is point at the first character. (We cannot rely on the scanner's last token position because Declare may be called long after the variable has been scanned.) R=adamk@chromium.org BUG=v8:5572 Review-Url: https://codereview.chromium.org/2447143005 Cr-Commit-Position: refs/heads/master@{#40613}
-
leszeks authored
Reuses (and renames) the SFI "mark for optimization" flag to also permit marking for baseline recompilation. The flag now represents a "tier up" request, and CompileLazy can get baseline code as well as optimized code. BUG=v8:5512 Review-Url: https://codereview.chromium.org/2448933002 Cr-Commit-Position: refs/heads/master@{#40612}
-
cbruni authored
BUG= Review-Url: https://codereview.chromium.org/2451173002 Cr-Commit-Position: refs/heads/master@{#40611}
-
leszeks authored
This is a new bytecode which behaves (for now) exactly like Call, except that in turbofan graph building we can set the ConvertReceiverMode to NotNullOrUndefined. I observe a 1% improvement on Box2D, I'd expect a similar improvement on other OOP heavy code. Review-Url: https://codereview.chromium.org/2450243002 Cr-Commit-Position: refs/heads/master@{#40610}
-
jgruber authored
'[...] accessor properties who have the attributes { [[Enumerable]]: false, [[Configurable]]: true } [...]' BUG=v8:5566 Review-Url: https://codereview.chromium.org/2452913002 Cr-Commit-Position: refs/heads/master@{#40609}
-
bmeurer authored
For inputs to truncating binary operations like <<, | or >>>, support all Oddballs not just undefined, true and false. This unifies treatment of these truncations in Crankshaft and TurboFan, and is very easy nowadays, since the memory layout of Oddball and HeapNumber is compatible. R=yangguo@chromium.org BUG=v8:5400 Review-Url: https://codereview.chromium.org/2452193003 Cr-Commit-Position: refs/heads/master@{#40608}
-
zhengxing.li authored
port df981a9f (r40577) original commit message: 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. BUG= Review-Url: https://codereview.chromium.org/2456503003 Cr-Commit-Position: refs/heads/master@{#40607}
-
- 26 Oct, 2016 11 commits
-
-
aseemgarg authored
R=titzer@chromium.org,binji@chromium.org BUG=v8:4614 Review-Url: https://codereview.chromium.org/2423883003 Cr-Commit-Position: refs/heads/master@{#40606}
-
rob authored
BUG=657568 TEST=Manually, see bug report Review-Url: https://codereview.chromium.org/2432163004 Cr-Commit-Position: refs/heads/master@{#40605}
-
cbruni authored
This is a poor-man's solution to trigger page interactions. BUG= Review-Url: https://codereview.chromium.org/2455623002 Cr-Commit-Position: refs/heads/master@{#40604}
-
bbudge authored
LOG=N BUG=v8:4124 Review-Url: https://codereview.chromium.org/2453813002 Cr-Commit-Position: refs/heads/master@{#40603}
-
heimbuef authored
Since ZoneLists are essentially non-standard ZoneVectors and have a bad growing behaviour (ZoneList-allocations make up ~50% of website parse zone memory) we should stop using them. The zone-containers are merely a clean-up, with none of them actually better suited to be used with zones. This new datastructure allows most operations of a LinkedList ( except pop_first and insertAt/removeAt) but uses about the same memory as a well-initialized ZoneVector/ZoneList (<3% overhead with reasonably large lists). It also never attempts to free memory again (which would not work in zones anyway). The ZoneChunkList is essentially a doubly-linked-list of arrays of variable size. Some test-results where I tried storing 16k pointers in different list types (lists themselves also zone-allocated): List type Zone memory used Time taken ----------------------------------------------------------------------- Zone array (for comparison) 131072 B Ideally initialized ZoneList 131088 B 0.062ms ChunkZoneList 134744 B 0.052ms <--new thing ZoneDeque 141744 B ZoneLinkedList 393264 B Initially empty ZoneList 524168 B 0.171ms <--right now ChunkZoneList only push_front 524320 B Review-Url: https://codereview.chromium.org/2449383002 Cr-Commit-Position: refs/heads/master@{#40602}
-
titzer authored
BUG=chromium:575167, v8:5507 R=rossberg@chromium.org,bradnelson@chromium.org CC=ahaas@chromium.org Review-Url: https://codereview.chromium.org/2447013004 Cr-Commit-Position: refs/heads/master@{#40601}
-
titzer authored
R=ahaas@chromium.org,rossberg@chromium.org,binji@chromium.org,bradnelson@chromium.org BUG=chromium:575167, chromium:659591 Review-Url: https://codereview.chromium.org/2440953002 Cr-Commit-Position: refs/heads/master@{#40600}
-
clemensh authored
If there is no stack trace (which happens), then at least print the location of the message. R=titzer@chromium.org,ahaas@chromium.org Review-Url: https://codereview.chromium.org/2450253002 Cr-Commit-Position: refs/heads/master@{#40599}
-
mythria authored
Turbofan requires a different tuning when compared to crankshaft. Crankshaft typically has faster compilation times when compared to turbofan. Hence, added a new parameter, so that crankshaft and turbofan can be tuned independently. OSRing too soon is not good for performance, especially for sunspider benchmarks. Since they are really small functions and optimizing them is more expensive than just executing unoptimized code. Tuning the code size threshold of the functions that can be OSRed from ignition. BUG=v8:4280,chromium:659111 Review-Url: https://codereview.chromium.org/2445203003 Cr-Commit-Position: refs/heads/master@{#40598}
-
bbudge authored
- Modifies RegisterConfiguration to specify complex aliasing on ARM 32. - Modifies RegisterAllocator to consider aliasing. - Modifies ParallelMove::PrepareInsertAfter to handle aliasing. - Modifies GapResolver to split wider register moves when interference with smaller moves is detected. - Modifies MoveOptimizer to handle aliasing. - Adds ARM 32 macro-assembler pseudo move instructions to handle cases where split moves don't correspond to actual s-registers. - Modifies CodeGenerator::AssembleMove and AssembleSwap to handle moves of different widths, and moves involving pseudo-s-registers. - Adds unit tests for FP operand interference checking and PrepareInsertAfter. - Adds more tests of FP for the move optimizer and register allocator. LOG=N BUG=v8:4124 Review-Url: https://codereview.chromium.org/2410673002 Cr-Commit-Position: refs/heads/master@{#40597}
-
clemensh authored
Just stumbled across this while doing https://codereview.chromium.org/2457433002/ R=mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2449103006 Cr-Commit-Position: refs/heads/master@{#40596}
-