Instead of constructing a temporary container for all LOperands of each
instruction, the register works directly on the LIR instructions that
provide an abstract interface for input/output/temp operands.
This saves allocation of zone memory and speeds up LIR construction,
but makes iterating over all uses in the register allocator slightly
more expensive because environment uses are stored in a linked list of
environments. We can fix this by using a flat representation of LOperands.
Review URL: http://codereview.chromium.org/6352006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6638 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Instead of spilling and then immediately restoring eax to resolve
memory to memory moves, the gap move resolver now tracks registers
that are known to be free and uses one if available. If not it spills
but restores lazily when the spilled value is needed or at the end of
the algorithm.
Instead of using esi for resolving cycles and assuming it is free to
overwrite because it can be rematerialized, the gap move resolver now
resolves cycles using swaps, possibly using a free register as above.
The algorithm is also changed to be simpler: a recursive depth-first
traversal of the move dependence graph. It uses a list of moves to be
performed (because it mutates the moves themselves), but does not use
any auxiliary structure other than the control stack. It does not
build up a separate list of scheduled moves to be interpreted by the
code generate, but emits code on the fly.
Review URL: http://codereview.chromium.org/6263005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6344 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch enables two new flags for the tools/test.py script;
--shard-count - giving the ability to split the tests to be run
into shard-count chunks.
--shard-run - giving the ability to specify which of the shards to actually run.
Example
tools/test.py -j15 --shard-count=2 --shard-run=1 mozilla
would split the mozilla tests into two chunks and run the tests in the first chunk
Running:
tools/test.py -j15 --shard-count=2 --shard-run=1 mozilla
tools/test.py -j15 --shard-count=2 --shard-run=2 mozilla
is equivalent (in terms of test coverage) of just running:
tools/test.py -j15 mozilla
In addition, tests are now sorted before they are returned from the
test specific ListTests methods (sputnik and mozilla tests where
already sorted before they where returned).
This change is needed to split a single test suite over two slaves on
the waterfall.
Review URL: http://codereview.chromium.org/6127003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6248 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
objectprint=on (defaults to off) option (which defines OBJECT_PRINT).
2. Added the ability to print objects to a specified file instead of
just stdout.
3. Added a use_verbose_printer flag (true by default) to allow some
object printouts to be less verbose when the flag is false.
4. Fixed a bug in VSNPrintF() where it can potentially write into an
empty char vector.
Patch by Mark Lam from Hewlett-Packard Development Company, LP
Review URL: http://codereview.chromium.org/5998001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6080 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is based on the structore used in chromium with a script wrapping the call to gyp itself and the default processing of common.gypi.
It is possible to build all our targets on Intel Linux for all architectures (ia32, x64 and ARM simulator). When this is committed I wil take a look at Windows.
See the README.txt file in the changelist for the current way of using it.
Review URL: http://codereview.chromium.org/5701001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6000 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
x64 where crankshaft is not the default. Add ability to add custom
expectations for running in this special crankshaft mode.
The expectations are not updated in this change. There are a couple of
bugs that I would like to fix before doing that. Otherwise the lists
will be very long. :)
Review URL: http://codereview.chromium.org/5787001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5962 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Make checks.h not depend on flags.h or global.h (or anything else except
include/v8stdint.h). Only checks.cc has the dependencies (so another
implementation of checks.cc can be provided by the preparser).
Now files depending on checks.h (using ASSERT macros) can include it
directly without depending on all of v8.
Review URL: http://codereview.chromium.org/4576001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5775 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Since 2.6.31 perf_events interface has been available in the
kernel. There's a nice tool called "perf" (linux-2.6/tools/perf) that
uses this interface and provides capabilities similar to oprofile. The
simplest form of its usage is just dumping the raw log (trace) of
events generated by the kernel. In this patch I'm adding a script
(tools/ll_prof.py) to build profiles based on perf trace and our code
log. All the heavy-lifting is done by perf. Compared to oprofile agent
this approach does not require recompilation and supports code moving
garbage collections.
Expected usage is documented in the ll_prof's help. Basically one
should run V8 under perf passing --ll-prof flag and then the produced
logs can be analyzed by tools/ll_prof.py.
The new --ll-prof flag enables logging of generated code object
locations and names (like --log-code), and also of their bodies, which
can be later disassembled and annotated by the script.
Review URL: http://codereview.chromium.org/3831002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5663 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
