This patch includes 3 fixes for veneers emission.
1) Block veneer pools emission in the PatchingAssembler.
2) Fix the check for veneer pool emission just before a constant pool.
3) Forbid copy of labels. The list of JumpTableEntry used to track the
deoptimization table entries would make copies of the labels when growing.
Doing so, it would confuse the Assembler that was tracking the labels via
pointers.
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/200133002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19941 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL enables RelocInfo pointers which live in the constant pool to be treated
as normal pointers by the slot buffer, avoiding the requirement of creating fake
RelocInfo objects during UpdateSlots() in order to update these slots. This
is possible because constant pool entries are just pointers and don't require
the RelocInfo machinary to be updated.
EmbeddedObject constant pool entries can be added untyped to the slot buffer,
while code targets are still typed in order to correctly update the target
address based on the relocated code object.
Note: this is required in order to enable OOL constant pool support on Arm, but
should be benifitial for the current inline constant pool used by Arm code.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/179813005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19772 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
It was only used for Math.log, and even then only in full code and in %_MathLog. For crankshafted code, Intel already used the FP operations directly, while the ARM/MIPS ports were a bit lazy and simply called the stub. The latter directly call the C library now without any cache. It would be possible to directly generate machine code if somebody has the time, from what I've seen out in the wild it should be only about a dozen instructions.
LOG=y
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/113343003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18344 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This removes tons of architecture-specific code and makes it easy to
experiment with other pseudo-RNG algorithms. The crankshafted code is
extremely good, keeping all things unboxed and doing only minimal
checks, so it is basically equivalent to the handwritten code.
When benchmarks are run without parallel recompilation, we get a few
percent regression on SunSpider's string-validate-input and
string-base64, but these benchmarks run so fast that the overall
SunSpider score is hardly affected and within the usual jitter. Note
that these benchmarks actually run even faster when we don't
crankshaft at all on the main thread (the regression is not caused by
bad code, it is caused by Crankshaft needing a few hundred microsecond
for compilation of a trivial function). Luckily, when parallel
recompilation is enabled, i.e. in the browser, we see no regression at
all!
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/68723002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17955 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
To keep the structure of the serializer more or less untouched, we use
some ingenious Corry-approved(TM) 3-step technology (a.k.a. "hack"):
* Create copies of code objects.
* Wipe out all absolute addresses in these copies.
* Write out the cleaned copies instead of the originals.
In conjunction with --random-seed, our snapshots are reproducible now.
BUG=v8:2885
R=bmeurer@chromium.org, erik.corry@gmail.com
Review URL: https://codereview.chromium.org/54823002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17473 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Previously, the result of target_reference_address() could only be
read, writing to it would have had an architecture-dependent effect,
e.g. writing into the code on ia32, a no-op on arm, etc.
This refactoring-only CL turns this into a simple getter, making it
impossible to use incorrectly.
More to come...
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/46583006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17467 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change means that code which is never executed is garbage collected immediately, and code which is only executed once is collected more quickly (limiting heap growth), however, code which is re-executed is reset to the young age, thus being kept around for the same number of GC generations as currently.
BUG=280984
R=danno@chromium.org, hpayer@chromium.org
Review URL: https://codereview.chromium.org/23480031
Patch from Ross McIlroy <rmcilroy@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17343 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* Allocations of AllocationSites occur in generated code, so generated code needs to be able to add to the list. For now I have a special hydrogen instruction, though it would be nice to use general purpose instructions.
* The snapshot contains AllocationSites, and these need to be re-threaded into the list on deserialization.
Something nice is that the AllocationSites are only created in old space, so a special new space visitor isn't required.
BUG=
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/18173013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15715 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change modifies code produced by BaseLoadStubCompiler::GenerateLoadCallback so that instead of calling AccessorGetter direcly it calls InvokeAccessorGetter which changes VM state and calls the actual callback. This way CPU profiler knows which external callback is being executed in this case. Indirect call happens only if CpuProfiler::is_profiling() is true.
This is exactly same change as r15116 with a build fix for test-api.cc
BUG=244580
TBR=danno@chromium.org
Review URL: https://codereview.chromium.org/16858013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15135 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This reverts commit f323d984a73bab345c4eab5c1907552ccfa7ccaa.
Broke compilation on the bots with an error that doesn't occur locally:
CXX(target) /mnt/data/b/build/slave/v8-linux-debug/build/v8/out/Debug/obj.target/cctest/test/cctest/test-bignum-dtoa.o
../test/cctest/test-api.cc: In function ‘void FastReturnValueCallback(const v8::FunctionCallbackInfo<v8::Value>&) [with T = int]’:
../test/cctest/test-api.cc:1129: error: insufficient contextual information to determine type
../test/cctest/test-api.cc: In function ‘void FastReturnValueCallback(const v8::FunctionCallbackInfo<v8::Value>&) [with T = unsigned int]’:
../test/cctest/test-api.cc:1136: error: insufficient contextual information to determine type
../test/cctest/test-api.cc: In function ‘void FastReturnValueCallback(const v8::FunctionCallbackInfo<v8::Value>&) [with T = double]’:
../test/cctest/test-api.cc:1143: error: insufficient contextual information to determine type
../test/cctest/test-api.cc: In function ‘void FastReturnValueCallback(const v8::FunctionCallbackInfo<v8::Value>&) [with T = bool]’:
../test/cctest/test-api.cc:1150: error: insufficient contextual information to determine type
../test/cctest/test-api.cc: In function ‘void FastReturnValueCallback(const v8::FunctionCallbackInfo<v8::Value>&) [with T = void]’:
../test/cctest/test-api.cc:1157: error: insufficient contextual information to determine type
CXX(target) /mnt/data/b/build/slave/v8-linux-debug/build/v8/out/Debug/obj.target/cctest/test/cctest/test-circular-queue.o
BUG=None
TBR=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/16838013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15117 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
