- 29 Dec, 2016 2 commits
-
-
danno authored
R=mvstanton@chromium.org TBR=rmcilroy@chromium.org Review-Url: https://codereview.chromium.org/2608683002 Cr-Commit-Position: refs/heads/master@{#41985}
-
v8-autoroll authored
Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/d79b0df..432074b TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org Review-Url: https://codereview.chromium.org/2601243002 Cr-Commit-Position: refs/heads/master@{#41984}
-
- 28 Dec, 2016 16 commits
-
-
machenbach authored
TBR=mstarzinger@chromium.org,bmeurer@chromium.org NOTRY=true Review-Url: https://codereview.chromium.org/2605113002 Cr-Commit-Position: refs/heads/master@{#41983}
-
gsathya authored
Add test as well. Add regression test for passing uninitialized promises to init hook BUG=v8:4643 Review-Url: https://codereview.chromium.org/2578173004 Cr-Commit-Position: refs/heads/master@{#41982}
-
jbarboza authored
Section 3.2 of the C++ standard states that destructor definitions implicitly "use" operator delete functions. Therefore, these operator delete functions must be defined even if they are never called by user code explicitly. http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#261 gcc allows them to remain as empty definitions. However, not all compilers allow this. (e.g. xlc on zOS) This pull request creates definitions which if ever called, result in an abort. R=danno@chromium.org,jochen@chromium.org BUG= LOG=N Review-Url: https://codereview.chromium.org/2588433002 Cr-Commit-Position: refs/heads/master@{#41981}
-
Michael Achenbach authored
Cr-Commit-Position: refs/heads/master@{#41980}
-
epertoso authored
We currently use BitcastTaggedToWord only in from the code assemblers to verify the correctness of the operation. BUG= Review-Url: https://codereview.chromium.org/2605073002 Cr-Commit-Position: refs/heads/master@{#41979}
-
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 4 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}
-