- 13 Oct, 2017 1 commit
-
-
Mathias Bynens authored
New code should use nullptr instead of NULL. This patch updates existing use of NULL to nullptr where applicable, making the code base more consistent. BUG=v8:6928,v8:6921 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I4687f5b96fcfd88b41fa970a2b937b4f6538777c Reviewed-on: https://chromium-review.googlesource.com/718338 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#48557}
-
- 06 Sep, 2017 1 commit
-
-
Clemens Hammacher authored
Up to now, each architecture defined all Register types as structs, with lots of redundancy. An often found comment noted that they cannot be classes due to initialization order problems. As these problems are gone with C++11 constexpr constants, I now tried making Registers classes again. All register types now inherit from RegisterBase, which provides a default set of methods and named constructors (like ::from_code, code(), bit(), is_valid(), ...). This design allows to guarantee an interesting property: Each register is either valid, or it's the no_reg register. There are no other invalid registers. This is guaranteed statically by the constexpr constructor, and dynamically by ::from_code. I decided to disallow the default constructor completely, so instead of "Register reg;" you now need "Register reg = no_reg;". This makes explicit how the Register is initialized. I did this change to the x64, ia32, arm, arm64, mips and mips64 ports. Overall, code got much more compact and more safe. In theory, it should also increase performance (since the is_valid() check is simpler), but this is probably not measurable. R=mstarzinger@chromium.org Change-Id: I5ccfa4050daf4e146a557970e9d37fd3d2788d4a Reviewed-on: https://chromium-review.googlesource.com/650927Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47847}
-
- 22 Aug, 2017 1 commit
-
-
Juliana Franco authored
This CL: - removes the trampoline pc from deoptimization input data and deoptimization state. This is no longer needed given that we added this information to the safepoint table in https://chromium-review.googlesource.com/c/v8/v8/+/596027). This should also fixed the regression mentioned in https://bugs.chromium.org/p/chromium/issues/detail?id=752873 - searches for the exception handler in the safepoint table. - removes the code used for patching which is no longer needed. Bug: v8:6563 Change-Id: I6cedc18c371f5707b7e0e1a8da409375ce1ebe5e Reviewed-on: https://chromium-review.googlesource.com/595547 Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47507}
-
- 02 Aug, 2017 1 commit
-
-
Juliana Franco authored
Replacing pc with trampoline on stack This CL is the follow up of https://chromium-review.googlesource.com/c/586707/ which used to crash when running the gc-stress bots. It seems to be working now. We now keep the trampoline PC in the Safepoint table and use that information to find SafepointEntries. There's some refactoring that can be done, such as changing the code for exceptions in a similar way and removing the trampoline from the DeoptimizationInputData. Will take care of this in the next CL. Bug: v8:6563 Change-Id: I8c0a2489de19e6d5fb4ebf1de7da1933726265b4 Reviewed-on: https://chromium-review.googlesource.com/596027 Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47066}
-
- 01 Aug, 2017 2 commits
-
-
Michael Achenbach authored
This reverts commit a01ac7cb. Reason for revert: Causes flakes on gc stress: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/14218 Original change's description: > Replacing pc with trampoline on stack > > This CL is the follow up of https://chromium-review.googlesource.com/c/586707/ > which used to crash when running the gc-stress bots. > It seems to be working now. We now keep the trampoline PC in the Safepoint > table and use that information to find SafepointEntries. > > There's some refactoring that can be done, such as changing the code for > exceptions in a similar way and removing the trampoline from the > DeoptimizationInputData. Will take care of this in the next CL. > > Bug: v8:6563 > Change-Id: I02565297093620023a1155b55d76a4dafcb54794 > Reviewed-on: https://chromium-review.googlesource.com/593622 > Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47030} TBR=jarin@chromium.org,bmeurer@chromium.org,jupvfranco@google.com Change-Id: Ie9929c9acae321a91014b76b9008f8835313e67d No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6563 Reviewed-on: https://chromium-review.googlesource.com/595927Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#47038}
-
Juliana Franco authored
This CL is the follow up of https://chromium-review.googlesource.com/c/586707/ which used to crash when running the gc-stress bots. It seems to be working now. We now keep the trampoline PC in the Safepoint table and use that information to find SafepointEntries. There's some refactoring that can be done, such as changing the code for exceptions in a similar way and removing the trampoline from the DeoptimizationInputData. Will take care of this in the next CL. Bug: v8:6563 Change-Id: I02565297093620023a1155b55d76a4dafcb54794 Reviewed-on: https://chromium-review.googlesource.com/593622 Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47030}
-
- 23 May, 2017 1 commit
-
-
Clemens Hammacher authored
Before emitting the safepoint table, remove consecutive identical entries (idential except for the pc of course). The lookup then searches for the last entry whose pc is <= the wanted pc. The lookup procedure can still be optimized to use binary search laster. This change decreases code size for wasm by 27.6% (on the unity benchmark). BUG=v8:6434 Change-Id: I03481721fe666cd2c50a383380c74b06edf39106 Reviewed-on: https://chromium-review.googlesource.com/512542 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#45491}
-
- 12 Apr, 2017 1 commit
-
-
Marja Hölttä authored
The biggest problem is isolate.h (this CL doesn't solve that yet). BUG=v8:5294 Change-Id: I56b32109f501c48facd99cd12ca6c8f427e188a9 Reviewed-on: https://chromium-review.googlesource.com/471487Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44613}
-
- 20 Sep, 2016 1 commit
-
-
heimbuef authored
This is some initial cleanup to keep /src clean. The AccountingAllocator is actually exclusively used by zones and this common subfolder makes that more clear. BUG=v8:5409 Review-Url: https://codereview.chromium.org/2344143003 Cr-Commit-Position: refs/heads/master@{#39558}
-
- 30 Sep, 2015 1 commit
-
-
mstarzinger authored
This enables linter checking for "readability/namespace" violations during presubmit and instead marks the few known exceptions that we allow explicitly. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1371083003 Cr-Commit-Position: refs/heads/master@{#31019}
-
- 30 Sep, 2014 1 commit
-
-
bmeurer@chromium.org authored
Review URL: https://codereview.chromium.org/618643002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24319 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 15 Sep, 2014 1 commit
-
-
jarin@chromium.org authored
We go back to patching the code for lazy deoptimization because ICs need the on-stack return address to read/update the IC address/state. The change also fixes bunch of tests, mostly by adding more deoptimization points. (We still need to add code to ensure lazy deopt patching does not overwrite ICs and other lazy deopts; this is coming next.) BUG= R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/568783002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23934 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 Aug, 2014 1 commit
-
-
jarin@chromium.org authored
Since the deopt patch address needs to be available during GC to resolve safepoints, we need to move it to the code object (instead of the deoptimization input data) - accessing a separate fixed array is not safe during GC. This CL adds a deoptimization_pc field to each safepoint. The fields points to the deoptimization block. The CL also fixes wrong register allocator constraints for frame states on calls. These should always live on the stack because registers are not preserved during a call. BUG= R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/504493002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23334 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 05 Aug, 2014 1 commit
-
-
jochen@chromium.org authored
BUG=none R=hpayer@chromium.org LOG=n Review URL: https://codereview.chromium.org/437993003 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22850 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 04 Aug, 2014 1 commit
-
-
bmeurer@chromium.org authored
This way we don't clash with the ASSERT* macros defined by GoogleTest, and we are one step closer to being able to replace our homegrown base/ with base/ from Chrome. R=jochen@chromium.org, svenpanne@chromium.org Review URL: https://codereview.chromium.org/430503007 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22812 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 Jul, 2014 1 commit
-
-
svenpanne@chromium.org authored
This is a mostly mechanical CL (more than 90% Emacs macros and query-replace-regexp) moving FILE*/StringStream*-based APIs to OStream-based APIs. There are a few places where this had to stop, otherwise the CL would be even bigger, but this can easily and incrementally cleaned up later. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/363323003 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22232 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Jun, 2014 1 commit
-
-
jochen@chromium.org authored
- this avoids using relative include paths which are forbidden by the style guide - makes the code more readable since it's clear which header is meant - allows for starting to use checkdeps BUG=none R=jkummerow@chromium.org, danno@chromium.org LOG=n Review URL: https://codereview.chromium.org/304153016 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21625 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 29 Apr, 2014 1 commit
-
-
bmeurer@chromium.org authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/259183002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21035 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 12 Mar, 2014 1 commit
-
-
jkummerow@chromium.org authored
Also add policing code to ensure that optimized frames can in fact lazily deopt at their respective current PC when we patch them for lazy bailout. BUG=chromium:350434 LOG=y R=jarin@chromium.org Review URL: https://codereview.chromium.org/194703008 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19834 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 Nov, 2013 1 commit
-
-
vegorov@chromium.org authored
This is controlled by two flags: --redirect_code_traces --redirect_code_traces_to=<filename> When redirection is enabled but --redirect_code_traces_to is not specified traces are written to a file code-<pid>-<isolate>.asm. This mangling scheme matches hydrogen.cfg and allows easy discovery of compilation artifacts in a multi-V8 environment (e.g. when compilation is traced from inside Chromium). D8 defines --redirect_code_traces_to=code.asm similar to hydrogen.cfg redirection. BUG= R=danno@chromium.org Review URL: https://codereview.chromium.org/43273004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17571 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Jun, 2013 1 commit
-
-
yangguo@chromium.org authored
R=svenpanne@chromium.org BUG= Review URL: https://chromiumcodereview.appspot.com/15691017 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14919 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Jun, 2012 1 commit
-
-
sanjoy@chromium.org authored
By passing around a Zone object explicitly we no longer need to do a TLS access at the sites that allocate memory from the current Zone. BUG= TEST= Review URL: https://chromiumcodereview.appspot.com/10534006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11761 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 04 Jun, 2012 1 commit
-
-
sanjoy@chromium.org authored
This CL changes some parts of the code to explicitly pass around a Zone. Not passing in a zone is okay too (in fact most of v8 still doesn't), but that may incur a TLS lookup. BUG= TEST= Review URL: https://chromiumcodereview.appspot.com/10443114 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11709 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 16 Nov, 2011 1 commit
-
-
fschneider@chromium.org authored
Changes the way we do lazy deoptimization: 1. For side-effect instructions, we insert the lazy-deopt call at the following LLazyBailout instruction. CALL GAP LAZY-BAILOUT ==> lazy-deopt-call 2. For other instructions (StackCheck) we insert it right after the instruction since the deopt targets an earlier deoptimization environment. STACK-CHECK GAP ==> lazy-deopt-call The pc of the lazy-deopt call that will be patched in is recorded in the deoptimization input data. Each Lithium instruction can have 0..n safepoints. All safepoints get the deoptimization index of the associated LAZY-BAILOUT instruction. On lazy deoptimization we use the return-pc to find the safepoint. The safepoint tells us the deoptimization index, which in turn finds us the PC where to insert the lazy-deopt-call. Additional changes: * RegExpLiteral marked it as having side-effects so that it gets an explicitlazy-bailout instruction (instead of treating it specially like stack-checks) * Enable target recording CallFunctionStub to achieve more inlining on optimized code. BUG=v8:1789 TEST=jslint and uglify run without crashing, mjsunit/compiler/regress-lazy-deopt.js Review URL: http://codereview.chromium.org/8492004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10006 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 06 May, 2011 1 commit
-
-
svenpanne@chromium.org authored
header which uses BASE_EMBEDDED and/or AllStatic. Note that still only 45 out of 135 headers in src/ can be used stand-alone, but at least this is a little bit more than before... Review URL: http://codereview.chromium.org/6931031 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7798 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 22 Mar, 2011 1 commit
-
-
sgjesse@chromium.org authored
TBR=ager@chromium.org Review URL: http://codereview.chromium.org/6715026 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7304 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Mar, 2011 3 commits
-
-
vitalyr@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7271 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
vitalyr@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7269 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
vitalyr@chromium.org authored
Review URL: http://codereview.chromium.org/6685088 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7268 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 08 Mar, 2011 1 commit
-
-
lrn@chromium.org authored
Ensure that there is always enough bytes between consequtive calls in unoptimized code to write a call instruction at the return points without overlapping. This handles the case where two return points were only four bytes apart (because the latter call was to a register). BUG=v8:1234 Review URL: http://codereview.chromium.org/6624091 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7089 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 04 Feb, 2011 1 commit
-
-
lrn@chromium.org authored
Add JSArrayLength, CallKnownFunction, and InstanceType operations. Remove LadGlobal and StoreGlobal again (they fail). Review URL: http://codereview.chromium.org/6347067 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6645 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 02 Feb, 2011 1 commit
-
-
kmillikin@chromium.org authored
Record a safepoint with a deoptimization id for throw in optimized code. We don't seem to much care what the AST ID is because we will not be using it for lazy deoptimization (throw doesn't return to the point of throw). For hygiene we use the actual ID of the throw expression. Throw is no longer a control-flow instruction, but it's followed by an unconditional abnormal exit. This is required to insert a simulate between the throw and the exit. Make our optimized treatment of Function.prototype.apply act like a call and have side effects. This ensures that it will get a lazy deoptimization environment. Use that deoptimization ID in the safepoint for the call. Deleting a property was also missing a deoptimization ID, though there was a deoptimization environment assigned to the instruction. Record the environment and use the deoptimization ID at the safepoint. Review URL: http://codereview.chromium.org/6250105 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6576 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 26 Jan, 2011 1 commit
-
-
karlklose@chromium.org authored
Refactor SafepointTableBuilder::DefineSafepoint and ARM LCodeGen::RecordSafepoint to use an enum for different kinds of safepoints. This change removes a lot of duplicated code and makes it easier to include new kinds of safepoints in the future. The remaining variants of LCodeGen::RecordSafepoint remain as a convinient way to record common safepoint kinds. BUG=http://code.google.com/p/v8/issues/detail?id=1043 TEST=none Review URL: http://codereview.chromium.org/6341008 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6505 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 14 Jan, 2011 1 commit
-
-
karlklose@chromium.org authored
This change provides fast code for a few special cases and calls the GenericBinaryOpStub for the rest. It also changes the register allocation in the generation of lithium instructions to use fixed registers that are compatible with the generic stub. This allocation can be change once we use a more flexible implementation. Finally, this change provides infrastructure to save double registers at safepoints, which is need to call the stub in deferred code. BUG= TEST= Review URL: http://codereview.chromium.org/6164005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6304 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 12 Jan, 2011 1 commit
-
-
vitalyr@chromium.org authored
This should enable calling runtime functions with arguments from deferred lithium code. Review URL: http://codereview.chromium.org/6125007 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6285 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 10 Jan, 2011 3 commits
-
-
sgjesse@chromium.org authored
TBR=ager@chromium.org Review URL: http://codereview.chromium.org/6205003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6254 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
sgjesse@chromium.org authored
TBR=ager@chromium.org Review URL: http://codereview.chromium.org/6206003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6253 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
sgjesse@chromium.org authored
On ARM the a constant pool can be emitted during the gap code generation which leads to larger gap code size BUG=v8:1018 Review URL: http://codereview.chromium.org/6125004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6252 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 Dec, 2010 2 commits
-
-
kasperl@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5922 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
kasperl@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5921 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-