- 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
-