- 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 3 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
-
kasperl@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5920 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-