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
o Only substitute constant values for full-words and not for
accidental partial matches.
o Keep the order of macros as in macros.py and allow depending on the
previous macros. We used to allow depending on macros that
happened to sort after the current one in the dictionary.
Review URL: http://codereview.chromium.org/2800042
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5022 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Fix issues so v8 could be built as a DLL.
-. get rid of all the compiler warning by moving dllexport/dllimport
to the individual members for classes which have inline members.
-. update v8 gyp to build v8.dll for chromium multi-dll version (win
and component==shared_library)
Note: most of the code are contributed by sjesse.
Code review URL: http://codereview.chromium.org/2882009/show
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5006 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Chromium build.
v8.gyp no longer sets any V8_TARGET_ARCH_* macro on the Mac. Instead, the
proper V8_TARGET_ARCH_* macro will be set by src/globals.h in the same way as
the V8_HOST_ARCH_* macro when it detects that no target macro is currently
defined. The Mac build will attempt to compile all ia32 and x86_64 .cc files.
#ifdef guards in each of these target-specific source files prevent their
compilation when the associated target is not selected. For completeness,
these #ifdef guards are also provided for the arm and mips .cc files.
BUG=706
TEST=x86_64 Mac GYP/Xcode-based Chromium build (still depends on other changes)
Review URL: http://codereview.chromium.org/2133003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4666 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
of having a list of virtual frame pointers in the jump
target we have one virtual frame, which is the frame that
all have to merge to to branch to that frame. The virtual
frame in the JumpTarget is inside the JumpTarget, rather than
being an allocated object that is pointed to. Unfortunately
this means that the JumpTarget class has to be able to see
the size of a VirtualFrame object to compile, which in turn
lead to a major reorganization of related .h files. The
actual change of functionality in this change is intended
to be minimal (we now assert that the virtual frames match
when using JumpTarget instead of just assuming that they do).
Review URL: http://codereview.chromium.org/1961004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4631 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The V8 GYP file now uses its own target architecture. It default to the standard target_arch, but can be set to a separate value. E.g. using
export GYP_DEFINES="target_arch=ia32 v8_target_arch=arm"
makes it possible to have the V8 ARM simulator be used in a IA32 build.
Added some checking of supported host/target architecture combinations.
Review URL: http://codereview.chromium.org/1790001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4490 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is to make possible enabling usage of the new profiling subsystem
in Chromium without much hassle. The idea is pretty simple: unless the
new profiling API is used, all works as usual, as soon as Chromium
starts to use the new API, it will work too.
Review URL: http://codereview.chromium.org/1635005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4382 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Instead of testing the value of a constant frame element to determine
the type we compute its type information at construction time.
This speeds up querying the type information during code generation.
This change also adds support for Integer32 constants and sets
the type information accordingly.
Review URL: http://codereview.chromium.org/1277001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4256 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
