in a non-test (ie, value or effect) context. (It is implicitly not in
a test context because the code generator does not support expressions
in a test context yet.)
Compilation is essentially the same as in the optimized code
generator. The expression (e0 || e1) is compiled as if it were
(let (temp = e0) temp ? temp : e1).
On ia32 and x64 a single shared ToBoolean stub is used to convert a
value to a flag. The inlined checks assumed by the stub are reordered
to compare to undefined (the common case in toplevel code?) first. On
ARM a call to the runtime is used. In the interest of code size no
checks are yet inlined on ARM.
Review URL: http://codereview.chromium.org/334006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3118 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
currently compiled the same as with the optimizing compiler: they are
cloned from a boilerplate object and the boilerplate objects are
lazily constructed.
Also changed argument pushing on ARM to use stm (store multiple),
which required changing the order of arguments to the runtime
functions DeclareGlobals and NewClosure. They were only used from
generated code.
Finally, changed the toplevel code generator so that stack pops to
discard a temporary became addition to the stack pointer on ia32 and
x64.
Review URL: http://codereview.chromium.org/303021
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3110 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
specification under development. The optimizations are patterned after
those previously done for CanvasPixelArray. This CL adds all of the
necessary framework but continues to use the generic KeyedLoadIC and
KeyedStoreIC code, to create a baseline for benchmarking purposes. The
next CL will add the optimized ICs to ic-ia32.cc and ic-x64.cc.
These new CanvasArray types have different semantics than
CanvasPixelArray; out-of-range values are clamped via C cast
semantics, which is cheaper than the clamping behavior specified by
CanvasPixelArray. Out-of-range indices raise exceptions instead of
being silently ignored.
As part of this work, pulled FloatingPointHelper::AllocateHeapNumber
up to MacroAssembler on ia32 and x64 platforms. Slightly refactored
KeyedLoadIC and KeyedStoreIC. Fixed encoding for fistp_d on x64 and
added a few more instructions that are needed for the new ICs. The
test cases in test-api.cc have been verified by hand to exercise all
of the generated code paths in the forthcoming specialized ICs.
Review URL: http://codereview.chromium.org/293023
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3096 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
while, and for loops.
Previously they were distinguished by a type field, which required
runtime asserts to avoid invalid nodes (since not all loop types have
the same internal structure). Now they C++ type system is used to
require well-formed loop ASTs.
Because they do not share compilation code, we had very large
functions in the code generators that merely did a runtime dispatch to
a specific implementation based on the type.
Review URL: http://codereview.chromium.org/269049
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3048 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The calls to GenericBinaryStub can now pass the arguments in registers instead of on the stack. It is supported for ADD, SUB, MUL and DIV. The convention in GenericBinaryStub is not changed so the left operand is passed in edx and the right one in eax. When the stub contains smi code arguments are always passed on the stack as the smi code has to have left and right operands on eax and ebx, so moving from edx,eax to eax,ebx is not worth it and the smi code also trashes the registers so if arguments where passed in registers they would have to be saved on the stack anyway.
Added flags to disable the use of certain Intel CPU features to make it easier to test different code paths.
Review URL: http://codereview.chromium.org/246075
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@3041 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Objects which require an additional fixed array to be allocated now have this allocated in generated code as well. Added allocation flags to the macro assembler new space allocation routines.
Changed the ia32 and x64 macro assemblers to take allocation flags to the allocation routines instead of boolean flag.
Review URL: http://codereview.chromium.org/201015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2832 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Factored out the allocation in new space from assembler code into the macro assembler. To support the current allocation patterns a number of different functions where required.
This is change is identical to http://codereview.chromium.org/174524 (committed in r2768 and reverted in r2769) except that line 710 in macro-assembler-ia32.cc is
cmp(result_end, Operand::StaticVariable(new_space_allocation_limit));
instead of
cmp(result, Operand::StaticVariable(new_space_allocation_limit));
and pre-submit fixes as well.
TBR=ager@chromium.org
Review URL: http://codereview.chromium.org/174600
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2771 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
snapshot creation in a better way.
Encode whether or not the stub should use sse3 instructions in the
minor key of the stub. The stubs generated during snapshot creation
will have sse3 disabled, but they will not be found when sse3 is
enabled. Therefore they will only affect the code generated as part
of the snapshot.
Review URL: http://codereview.chromium.org/172086
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2705 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Marsaglia's multiply-with-carry instead of mixing the
bits obtained from calling the system random() twice.
This seems to be a bit faster and gives a better
distribution than the system random() in particular on
Windows.
Review URL: http://codereview.chromium.org/126113
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2159 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* Identify heap numbers that contain non-Smi int32s and do bit
ops on them without calling the fp hardware or emulation.
* Identify results that are non-Smi int32s and write them into
heap numbers without calling the fp hardware or emulation.
* Do unary minus on heap numbers without going into the runtime
system.
* On add, sub and mul if we have both Smi and heapnumber inputs
to the same operation then convert the Smi to a double and do
the op without going into runtime system. This also applies
if we have two Smi inputs but the result is not Smi.
Review URL: http://codereview.chromium.org/119241
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2131 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
deferred code snippets are highly stylized. They always make a call
to a stub or the runtime and then return. This change takes advantage
of that.
Creating a deferred code object now captures a snapshot of the
registers in the virtual frame. The registers are automatically saved
on entry to the deferred code and restored on exit.
The clients of deferred code must ensure that there is no change to
the registers in the virtual frame (eg, by allocating which can cause
spilling) or to the stack pointer. That is currently the case.
As a separate change, I will add either code to verify this constraint
or else code to forbid any frame effect.
The deferred code itself does not use the virtual frame or register
allocator (or even the code generator). It is raw macro assembler
code.
Review URL: http://codereview.chromium.org/118226
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2112 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
My assumption that log initialization happens somewhere near the stack's bottom is true for V8's sample shell but isn't true for Chromium, causing many otherwise valid stack addresses to be thrown out. The solution proposed is to save stack pointer value for the outermost JS function in ThreadLocalTop similar to c_entry_fp.
Implemented only for IA-32. Currently I'm not dealing with profiling on ARM and x86-64 anyway.
Review URL: http://codereview.chromium.org/112082
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2086 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
called from within a loop or not. In the past we lost the
information if a call site went megamorphic before a lazily
compiled callee was called for the first time. Now we track
that correctly (this is an issue that affects richards).
We still don't manage to track the in-loop state through a
constructor call, since constructor calls use LoadICs instead
of CallICs. This issue affects delta-blue. So in this patch
we assume that lazy compilations that don't happen through a
CallIC happen from inside a loop. I have an idea to fix this
but this patch is big enough already.
With our improved tracking of in-loop state I have switched
off the inlining of in-object loads for code that is not in
a loop. This benefits compile speed. One issue is that
eagerly compiled code now doesn't get the in-object loads
inlined. We need to eagerly compile less code to fix this.
Review URL: http://codereview.chromium.org/115744
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2046 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This issue was raised by Brett Wilson while reviewing my changelist for readability. Craig Silverstein (one of C++ SG maintainers) confirmed that we should declare one namespace per line. Our way of namespaces closing seems not violating style guides (there is no clear agreement on it), so I left it intact.
Review URL: http://codereview.chromium.org/115756
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2038 ce2b1a6d-e550-0410-aec6-3dcde31c8c00