- 28 Dec, 2016 11 commits
-
-
joransiu authored
In fast-allocate, the path that leverages Add Mem-Imm fails to take into account that the allocation size may be adjusted by kDoubleSize/2 for alignment. Limit this instruction to 64-bit only. Also guard PFDs with the proper facility check. R=jyan@ca.ibm.com, michael_dawson@ca.ibm.com, bjaideep@ca.ibm.com BUG= Review-Url: https://codereview.chromium.org/2605063002 Cr-Commit-Position: refs/heads/master@{#41978}
-
danno authored
R=ishell@chromium.org LOG=N Review-Url: https://codereview.chromium.org/2608433003 Cr-Commit-Position: refs/heads/master@{#41977}
-
danno authored
Before this patch, loops in deferred code would defeat the propagation of the deferred flag, since back edges would usually not come from deferred blocks, thus stoping the forward propagation of the deferred flag at loop headers. This patch ensures that back edges are ignored in the deferred propations, properly placing loops dominated by deferred labels and the code that follows them into deferred code. R=epertoso@chromium.org LOG=N Review-Url: https://codereview.chromium.org/2606923002 Cr-Commit-Position: refs/heads/master@{#41976}
-
danno authored
Instead of loading the address both the limit and top pointers, rely on the property that the limit pointer is always directly after the top pointer so that it can be loaded with the limit pointer's address plus a fixed offset. This generates smaller code and reduces the number of registers required by the allocation sequence by one. LOG=N R=epertoso@chromium.org Review-Url: https://codereview.chromium.org/2605043002 Cr-Commit-Position: refs/heads/master@{#41975}
-
danno authored
Before this patch, Loads generated in the CSA on x64 that have a zero offset displacement will add a zero to the effective address rather than using an addressing mode that folds away the zero. This functionality already exists on ia32, but the port wasn't purely mechanical so it hadn't been done on x64. R=epertoso@chromium.org LOG=N Review-Url: https://codereview.chromium.org/2602893002 Cr-Commit-Position: refs/heads/master@{#41974}
-
ishell authored
... and add explicit CallPrologue/CallEpilogue callbacks to CodeAssemblerState instead. This will allow IntepreterAssembler to use any other helper assembler. TBR=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2600183004 Cr-Commit-Position: refs/heads/master@{#41973}
-
danno authored
Specifically, don't propage "needs_frame" up through non-deferred -> deferred block transitions where there are multiple edges from the non-deferred to deferred code. LOG=N R=epertoso@chromium.org Review-Url: https://codereview.chromium.org/2606893002 Cr-Commit-Position: refs/heads/master@{#41972}
-
danno authored
Recognize and emit in-memory comparisons of 8-bit and 16-bit values with immediate values that fit. LOG=N R=epertoso@chromium.org Review-Url: https://codereview.chromium.org/2605863002 Cr-Commit-Position: refs/heads/master@{#41971}
-
mvstanton authored
This aids in TurboFan concurrent compilation, a general good. TBR for Ross, on vacation... TBR=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2607563002 Cr-Commit-Position: refs/heads/master@{#41970}
-
epertoso authored
BUG= Review-Url: https://codereview.chromium.org/2601043002 Cr-Commit-Position: refs/heads/master@{#41969}
-
v8-autoroll authored
Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/7018464..d79b0df TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review-Url: https://codereview.chromium.org/2607693002 Cr-Commit-Position: refs/heads/master@{#41968}
-
- 27 Dec, 2016 12 commits
-
-
adamk authored
The rest of the cases I found are places where the runtime function calls some API that takes handles but itself uses HandleScopes internally where needed. R=gsathya@chromium.org BUG=v8:5783 Review-Url: https://codereview.chromium.org/2600993002 Cr-Commit-Position: refs/heads/master@{#41967}
-
bjaideep authored
Reason for revert: Original CL was reverted, https://codereview.chromium.org/2597163002 Original issue's description: > PPC/s390: [TypeFeedbackVector] Root literal arrays in function literals slots > > Port 93df0940 > > Original Commit Message: > > Literal arrays and feedback vectors for a function can be garbage > collected if we don't have a rooted closure for the function, which > happens often. It's expensive to come back from this (recreating > boilerplates and gathering feedback again), and the cost is > disproportionate if the function was inlined into optimized code. > > To guard against losing these arrays when we need them, we'll now > create literal arrays when creating the feedback vector for the outer > closure, and root them strongly in that vector. > > R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com > BUG=v8:5456 > LOG=N > > Review-Url: https://codereview.chromium.org/2592043003 > Cr-Commit-Position: refs/heads/master@{#41898} > Committed: https://chromium.googlesource.com/v8/v8/+/19aa7a20b0c39ea9ef81d6e021863183732f82c0 R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:5456 LOG=N Review-Url: https://codereview.chromium.org/2601793002 Cr-Commit-Position: refs/heads/master@{#41966}
-
littledan authored
Review-Url: https://codereview.chromium.org/2595403002 Cr-Commit-Position: refs/heads/master@{#41965}
-
gsathya authored
R=adamk@chromium.org BUG=v8:5783 Review-Url: https://codereview.chromium.org/2608433002 Cr-Commit-Position: refs/heads/master@{#41964}
-
adamk authored
R=gsathya@chromium.org BUG=v8:5783 Review-Url: https://codereview.chromium.org/2603783003 Cr-Commit-Position: refs/heads/master@{#41963}
-
adamk authored
The only caller was the API, and it can just as easily use the TurboFan version. R=franzih@chromium.org Review-Url: https://codereview.chromium.org/2603493002 Cr-Commit-Position: refs/heads/master@{#41962}
-
adamk authored
The TF version of this operation was missing a ToObject coercion, so failed to do @@toStringTag lookups when passed primitive values. R=franzih@chromium.org BUG=v8:5780 Review-Url: https://codereview.chromium.org/2597323002 Cr-Commit-Position: refs/heads/master@{#41961}
-
bakkot authored
This syntax was formerly legal per ECMAScript, but has been a SyntaxError for some time now. V8 deviates from spec in that it is instead a runtime error; we'd like to know if we can get away with removing it (at least in sloppy mode) or if the spec should be changed. c.f. https://github.com/tc39/ecma262/issues/257#issuecomment-195106880 Also add self to authors file BUG=v8:4480 Review-Url: https://codereview.chromium.org/2599253002 Cr-Commit-Position: refs/heads/master@{#41960}
-
littledan authored
This patch moves the creation of the Intl constructors from JavaScript to C++ in bootstrapper.cc, to match all of the other builtins exposed to the web. BUG=v8:5751 Review-Url: https://codereview.chromium.org/2586763002 Cr-Commit-Position: refs/heads/master@{#41959}
-
littledan authored
Revert of [intl] Remove redundant type checking system (patchset #3 id:40001 of https://codereview.chromium.org/2591203002/ ) Reason for revert: Issue https://bugs.chromium.org/p/chromium/issues/detail?id=677055 . I'll send out a follow-on reland, as it should still be possible to eliminate the redundant type system. Original issue's description: > [intl] Remove redundant type checking system > > Previously, the Intl implementation tracked types two ways: > - In the intl_initialized_marker_symbol > - In various named properties of the intl_impl_object_symbol value > > As far as I can tell, these will never disagree with each other, > modulo bugs in Intl itself. This patch removes the second type > checking system. > > BUG=v8:5751 > > Review-Url: https://codereview.chromium.org/2591203002 > Cr-Commit-Position: refs/heads/master@{#41941} > Committed: https://chromium.googlesource.com/v8/v8/+/0d5561b64d34129e6546947255e543c219c61655 TBR=yangguo@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=v8:5751 Review-Url: https://codereview.chromium.org/2601783002 Cr-Commit-Position: refs/heads/master@{#41958}
-
ulan authored
BUG=chromium:675911 Review-Url: https://codereview.chromium.org/2593043002 Cr-Commit-Position: refs/heads/master@{#41957}
-
danno authored
Review-Url: https://codereview.chromium.org/2600763002 Cr-Commit-Position: refs/heads/master@{#41956}
-
- 26 Dec, 2016 2 commits
-
-
machenbach authored
BUG=chromium:677032 NOTRY=true TBR=titzer@chromium.org Review-Url: https://codereview.chromium.org/2607473002 Cr-Commit-Position: refs/heads/master@{#41955}
-
machenbach authored
BUG=chromium:673246 NOTRY=true TBR=tandrii@chromium.org Review-Url: https://codereview.chromium.org/2598323002 Cr-Commit-Position: refs/heads/master@{#41954}
-
- 25 Dec, 2016 1 commit
-
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/d14a3a7..bdc04ca TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review-Url: https://codereview.chromium.org/2604693002 Cr-Commit-Position: refs/heads/master@{#41953}
-
- 24 Dec, 2016 3 commits
-
-
Michael Achenbach authored
Cr-Commit-Position: refs/heads/master@{#41952}
-
machenbach authored
Revert of [heap] Report wrappers after processing the marking deque incrementally (patchset #5 id:80001 of https://codereview.chromium.org/2604583002/ ) Reason for revert: Speculative revert. Might block the roll: https://codereview.chromium.org/2606503002/ The gpu bots crash with this stack top:v88internal18IncrementalMarking25AdvanceIncrementalMarkingEdNS1_16CompletionActionENS1_21ForceCompletionActionENS0_10StepOrigin Original issue's description: > [heap] Report wrappers after processing the marking deque incrementally > > BUG=chromium:676700, chromium:468240 > > Review-Url: https://codereview.chromium.org/2604583002 > Cr-Commit-Position: refs/heads/master@{#41946} > Committed: https://chromium.googlesource.com/v8/v8/+/1344e3a9caba4206758623630e3c3dd6872879e7 TBR=hpayer@chromium.org,mlippautz@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:676700, chromium:468240 Review-Url: https://codereview.chromium.org/2604673002 Cr-Commit-Position: refs/heads/master@{#41951}
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/69a30f6..d14a3a7 Rolling v8/test/test262/harness: https://chromium.googlesource.com/external/github.com/test262-utils/test262-harness-py/+log/cbd968f..0f2acdd Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/810f05a..1e8a2ca Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/68d808f..7018464 TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review-Url: https://codereview.chromium.org/2599293004 Cr-Commit-Position: refs/heads/master@{#41950}
-
- 23 Dec, 2016 11 commits
-
-
gsathya authored
TBR=adamk@chromium.org Review-Url: https://codereview.chromium.org/2604483005 Cr-Commit-Position: refs/heads/master@{#41949}
-
machenbach authored
Revert of Disable the CompilerDispatcher if we don't have idle time (patchset #1 id:1 of https://codereview.chromium.org/2600743002/ ) Reason for revert: [Sheriff] Speculative revert since we got persistent timeouts on win32 debug: https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug/builds/6417 Please reland if it doesn't help. Original issue's description: > Disable the CompilerDispatcher if we don't have idle time > > Since we can't do all steps on background threads, we need idle time to > work > > BUG=v8:5215 > R=danno@chromium.org > > Review-Url: https://codereview.chromium.org/2600743002 > Cr-Commit-Position: refs/heads/master@{#41944} > Committed: https://chromium.googlesource.com/v8/v8/+/a0d9eb346bba90aa0b32a2d3184cbbfd6adb243e TBR=danno@chromium.org,jochen@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5215 Review-Url: https://codereview.chromium.org/2600773002 Cr-Commit-Position: refs/heads/master@{#41948}
-
gsathya authored
BUG=v8:5343 Review-Url: https://codereview.chromium.org/2604483002 Cr-Commit-Position: refs/heads/master@{#41947}
-
mlippautz authored
BUG=chromium:676700, chromium:468240 Review-Url: https://codereview.chromium.org/2604583002 Cr-Commit-Position: refs/heads/master@{#41946}
-
littledan authored
Fix issue created by patch https://codereview.chromium.org/2582993002/ CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng TBR=yangguo@chromium.org BUG=v8:4360 Review-Url: https://codereview.chromium.org/2599973002 Cr-Commit-Position: refs/heads/master@{#41945}
-
jochen authored
Since we can't do all steps on background threads, we need idle time to work BUG=v8:5215 R=danno@chromium.org Review-Url: https://codereview.chromium.org/2600743002 Cr-Commit-Position: refs/heads/master@{#41944}
-
littledan authored
ECMA 402 v2 made Intl constructors more strict in terms of how they would initialize objects, refusing to initialize objects which have already been constructed. However, when Chrome tried to ship these semantics, we ran into web compatibility issues. This patch tries to square the circle and implement the simpler v2 object semantics while including a compatibility workaround to allow objects to sort of be initialized later, storing the real underlying Intl object in a symbol-named property. The new semantics are described in this PR against the ECMA 402 spec: https://github.com/tc39/ecma402/pull/84 BUG=v8:4360, v8:4870 LOG=Y Review-Url: https://codereview.chromium.org/2582993002 Cr-Commit-Position: refs/heads/master@{#41943}
-
jarin authored
BUG=v8:5756 Review-Url: https://codereview.chromium.org/2596843002 Cr-Commit-Position: refs/heads/master@{#41942}
-
littledan authored
Previously, the Intl implementation tracked types two ways: - In the intl_initialized_marker_symbol - In various named properties of the intl_impl_object_symbol value As far as I can tell, these will never disagree with each other, modulo bugs in Intl itself. This patch removes the second type checking system. BUG=v8:5751 Review-Url: https://codereview.chromium.org/2591203002 Cr-Commit-Position: refs/heads/master@{#41941}
-
mlippautz authored
1) Alternate between processing v8 and wrappers 2) Once v8 is empty, try 3 rounds of finding the fixpoint between v8 and wrappers 3) After that, finalize once v8 marking deque is empty again Reland fixed: Toggle needs to be IncrementalMarking global as we need to properly alternate tracing v8 and wrappers. BUG=chromium:468240, chromium:668164 Review-Url: https://codereview.chromium.org/2599283002 Cr-Commit-Position: refs/heads/master@{#41940}
-
danno authored
LoadFieldStub is the last Crankshaft/Hydrogen stub that stands in the way of being able to run --ignition-staging --turbo without any Crankshaft support, even for ICs/stubs. Review-Url: https://codereview.chromium.org/2595343002 Cr-Commit-Position: refs/heads/master@{#41939}
-