This improves the generated code for HSeqStringSetChar across
all platforms, taking advantage of constant operands whenever
possible. It also drops the unused DefineSameAsFirst constraint
for the register allocator on x64 and ia32, where it caused
unnecessary spills when the string operand was live across the
HSeqStringSetChar instruction.
A new GVN flag StringChars is introduced to express dependencies
between HSeqStringSetChar, HStringCharCodeAt and the upcoming
HSeqStringGetChar (the GVNFlags type is now 64bit in size).
Also improves the test case.
TEST=mjsunit/string-natives
R=mstarzinger@chromium.org, yangguo@chromium.org
Review URL: https://codereview.chromium.org/57383004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17521 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In the process:
- Add a command-line flag --opt-code-positions to track source position information throughout optimized code.
- Add a subclass of the hydrogen graph builder to ensure that the source position is properly set on the graph builder for all generated hydrogen code.
- Overhaul handling of source positions in hydrogen to ensure they are passed through to generated code consistently and in most cases transparently.
Originally reviewed in this CL: https://codereview.chromium.org/24957003/
Review URL: https://codereview.chromium.org/29123008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17295 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Right now we eagerly save all allocatable double registers upon
entry to every Hydrogen code stub that uses HCallRuntime, and
restore them when we return. Since the HCallRuntime is on the
fallback path for code stubs, this is both a waste of time and
stack space in almost every case.
This patch adds a flag to the HCallRuntime, which controls whether
the instruction saves the double register itself (using the save
doubles flag for the CEntryStub), or whether its up the surrounding
code to handle the clobbering of double registers.
R=danno@chromium.org
Review URL: https://codereview.chromium.org/23530066
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17044 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Since the per-context random number generator is now
properly seeded upon context creation, we do not need
to check for lazy-initialization anymore, and so we
can implement the HRandom instruction w/o having to
call into the C function (which means we don't need
to MarkAsCall anymore).
TEST=cctest/test-random
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/23478031
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16684 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Use V8_FINAL and V8_OVERRIDE in Ast classes.
- Use V8_FINAL and V8_OVERRIDE in Lithium mips backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium arm backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium x64 backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium ia32 backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium classes.
- Use V8_FINAL and V8_OVERRIDE in Hydrogen classes.
TBR=dslomov@chromium.org
Review URL: https://codereview.chromium.org/22796020
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16244 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Use V8_FINAL and V8_OVERRIDE in objects.
- Use V8_FINAL and V8_OVERRIDE in Ast classes.
- Use V8_FINAL and V8_OVERRIDE in Lithium mips backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium arm backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium x64 backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium ia32 backend.
- Use V8_FINAL and V8_OVERRIDE in Lithium classes.
- Use V8_FINAL and V8_OVERRIDE in Hydrogen classes.
R=dslomov@chromium.org
Review URL: https://codereview.chromium.org/23064017
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16232 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch is to enhance the source code line information for profiler.
For the Hydrogen compilation, most of the source code line information
is not copied from the HInstruction the to corresponding LInstruction.
This patch defines one PositionBits field for LInstruction and copies the
sorce code position value from the HInstruction.
When Generating the native code, we use RecordPosition(..) function to
write LInstruction's position value to position recorder.
For the MIPS platform, I did not touch because I have no devices
to verify the modification on it.
R=danno@chromium.org
Review URL: https://codereview.chromium.org/21042003
Patch from Chunyang Dai <chunyang.dai@intel.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16114 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change implements a simple data-flow analysis pass over captured
objects to the existing escape analysis. It tracks the state of values
in the Hydrogen graph through CapturedObject marker instructions that
are used to construct an appropriate translation for the deoptimizer to
be able to materialize these objects again.
This can be considered a combination of scalar replacement of loads and
stores on captured objects and sinking of unused allocations.
R=titzer@chromium.org
TEST=mjsunit/compiler/escape-analysis
Review URL: https://codereview.chromium.org/21055011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16098 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
I'd like to propagate bailout reason to cpu profiler.
So I need to save it into heap object SharedFunctionInfo.
But:
1) all bailout reason strings spread across all the sources.
2) they are native strings and if I convert them into String then I may have a performance issue.
3) one byte is enough for 184 bailout reasons. Otherwise we need 8 bytes for the pointer.
Also I think it would be nice to have error strings collected in one place.
In that case we will get additional benefits:
It allows us to keep this set of messages under control.
It gives us a chance to internationalize them.
It slightly reduces the binary footprint.
From the other hand the developers have to add new strings into that enum.
BUG=
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/20843012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16024 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 essentially relands r14930 and r14935 with adaptions to the current
code base. It models the instantiation of an implicit receiver for
CallNew nodes in hydrogen using HAllocate together with generic stores
instead of one specialized HAllocateObject instruction, hence creating a
single choking point for inlined allocation in optimized code.
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/19207002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15673 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
