Notes:
- For now, just adds the missing type info fields to the AST nodes directly.
I'd like to factor that out more nicely in a follow-up CL.
- All type feedback now is uniformly collected through AST nodes'
RecordTypeFeedback functions. At some point, this logic should be moved
out of ast.cc.
- The typing pass currently simulates the exact same conditions under
which feedback was collected in Hydrogen before. That also should be
made more generic in the future.
- Type information itself is unchanged. Making it more regular is
yet more future work.
Some additional cleanups:
- Lifted out nested class ObjectLiteral::Property, to enable forward declaration.
- Moved around some auxiliary enums.
R=svenpanne@chromium.org
BUG=
Review URL: https://codereview.chromium.org/14990014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14825 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch defines new makefile command line paramaters to better control the
ARM specific options. The new paramters are
* armfpu = vfp, vfpv3-d16, vfpv3, neon.
* armfloatabi = softfp, hard
* armneon = on
* armthumb = on, off
* armtest = on
One existing paratemer has been modified:
* armv7 = true, false
A number of parameters have been deprecated (but are still working):
* hardfp = on, off
* vfp2 = off
* vfp3 = off
the armtest paratmer when set to "on" will lock the options used during compile
time at runtime. This allows for example to easily test the ARMv6 build on an
ARMv7 platform without having to worry about features detected at runtime. When
not specified the compiler default will be used meaning it is not necessary
anymore to specify hardfp=on when natively building on an hardfp platform.
The shell help now prints the target options and features detected.
BUG=none
TEST=none
Review URL: https://chromiumcodereview.appspot.com/14263018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14288 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a first step to having profiler sampler implementation in one file with platform capabilities guarded with #ifdef. Otherwise we have very similar implementations scattered over platform-*.cc files which makes it hard to see differences and make changes.
The next steps will be to merge win32, Mac OS X and Cygwin implementations into sampler.cc They suspend profiled thread instead of sending a signal but apart from that the logic is pretty much the same. Then I'm going to move sampler-related code from log.* into sampler.*
BUG=None
Review URL: https://codereview.chromium.org/13852005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14265 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* src/contexts.h:
* src/bootstrapper.cc (InitializeExperimentalGlobal): Make generator
meta-objects, and store maps for constructing generator functions
and their prototypes.
* src/factory.h:
* src/factory.cc (MapForNewFunction): New helper.
(NewFunctionFromSharedFunctionInfo): Use the new helper.
* src/heap.cc (AllocateFunctionPrototype, AllocateInitialMap): For
generators, allocate appropriate prototypes and maps.
* src/code-stubs.h:
* src/arm/code-stubs-arm.h:
* src/arm/full-codegen-arm.h:
* src/ia32/code-stubs-ia32.h:
* src/ia32/full-codegen-ia32.h:
* src/x64/code-stubs-x64.h:
* src/x64/full-codegen-x64.h: Allow fast closure creation for generators,
using the appropriate map.
* test/mjsunit/harmony/builtins.js: Add a special case for
GeneratorFunctionPrototype.prototype.__proto__.
BUG=
TEST=mjsunit/harmony/generators-runtime
Review URL: https://codereview.chromium.org/13192004
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14236 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Rename v8_base, v8_nosnapshot, and mksnapshot to include a suffix of
.<(v8_target_arch). This allows multiple target architectures to be
built in the Android build system, which uses a single shared directory
structure for building host binaries.
BUG=
Review URL: https://codereview.chromium.org/12790011
Patch from Richard Coles <torne@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14209 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
instead of direct_dependent_settings - with V8 headers
being included in other headers, the former works much better.
This is a configuration that is not used for Google Chrome
neither V8 buildbot, and has been tested for its intended
use case (Linux distributions).
BUG=none
Review URL: https://codereview.chromium.org/12378092
Patch from Paweł Hajdan Jr. <phajdan.jr@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13822 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Add --harmony-symbols flag.
- Add Symbol constructor; allow symbols as (unreplaced) return value from constructors.
- Introduce %CreateSymbol and %_IsSymbol natives and respective instructions.
- Extend 'typeof' code generation to handle symbols.
- Extend CompareIC with a UNIQUE_NAMES state that (uniformly) handles internalized strings and symbols.
- Property lookup delegates to SymbolDelegate object for symbols, which only carries the toString method.
- Extend Object.prototype.toString to recognise symbols.
Per the current draft spec, symbols are actually pseudo objects that are frozen with a null prototype and only one property (toString). For simplicity, we do not treat them as proper objects for now, although typeof will return "object". Only property access works as if they were (frozen) objects (via the internal delegate object).
(Baseline CL: https://codereview.chromium.org/12223071/)
R=mstarzinger@chromium.org
BUG=v8:2158
Review URL: https://codereview.chromium.org/12296026
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13786 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In the traditional MIPS naming scheme, "mips" is used for
big-endian mips and "mipsel" is used for little-endian mips.
In V8 the "mips" build is little-endian, so the "mips" target is
renamed to "mipsel" to be compliant with the traditional MIPS
naming scheme.
This change is also required for supporting the Chromium project on MIPS.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10695114
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12047 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In this design maps contain descriptor arrays, which in turn can contain transition arrays. If transitions are needed when no descriptor array is present, a descriptor array without real descriptors is inserted just so it can point at the transition array.
The transition array does not contain details about the field it transitions to. In order to weed out transitions to FIELDs from CONSTANT_FUNCTION (what used to be MAP_TRANSITION vs CONSTANT_TRANSITION), the transition needs to be followed and the details need to be looked up in the target map. CALLBACKS transitions are still easy to recognize since the transition targets are stored as an AccessorPair containing the maps, rather than the maps directly.
Currently AccessorPairs containing a transition and an accessor are shared between the descriptor array and the transition array. This simplifies lookup since we only have to look in one of both arrays. This will change in subsequent revisions, when descriptor arrays will become shared between multiple maps, since transitions cannot be shared.
Review URL: https://chromiumcodereview.appspot.com/10697015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11994 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Note that in order to build for 64bits mode, you'll have
to specify the target architecture explicitely, the default
is still 32bits for Mac OS X.
Example with make and gcc:
$ export GYP_GENERATORS=make
$ make dependencies
$ make -j 8 library=shared x64.release
Example with make and clang:
$ export GYP_GENERATORS=make
$ export CC=/usr/bin/clang
$ export CXX=/usr/bin/clang++
$ export GYP_DEFINES="clang=1"
$ make dependencies
$ make -j 8 library=shared x64.release
Example with xcode:
$ export GYP_GENERATORS=xcode
$ build/gyp_v8 -Dtarget_arch=x64
$ xcodebuild -project build/all.xcodeproj -configuration Release
Contributed by Filipe David Manana <fdmanana@gmail.com>
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9808065
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11199 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL:
- Adds a new trait parameter to LazyInstance to let it initialize the instance
without paying the cost of atomic operations (which are expensive on Mac).
This only works for users who don't care about thread-safety and this is now
the default initialization trait used by LazyInstance in v8.
- Reverts the changes that were made in r11010 in isolate.{cc,h}. That lets
Isolate's accessors be as cheap as they were before (but adds one static initializer).
- Adds OS::PostSetup() used to initialize the math functions which depend on CPU features.
That lets the math functions get rid of CallOnce().
BUG=118686
Review URL: https://chromiumcodereview.appspot.com/9873023
Patch from Philippe Liard <pliard@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11198 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change includes two CLs by pliard@chromium.org:
1. http://codereview.chromium.org/9447052/ (Add CallOnce() and simple LazyInstance implementation):
Note that this implementation of LazyInstance does not handle global destructors (i.e. the lazy instances are never deleted).
This CL was initially reviewed on codereview.appspot.com:
http://codereview.appspot.com/5687064/
2. http://codereview.chromium.org/9455088/ (Remove static initializers in v8):
This CL depends on CL 9447052 (adding CallOnce and LazyInstance).
It is based on a patch sent by Digit.
With this patch applied, we have only one static initializer left (in atomicops_internals_x86_gcc.cc). This static initializer populates a structure used by x86 atomic operations. It seems that we can hardly remove it. If possible, it will be removed in a next CL.
This CL also modifies the presubmit script to check the number of static initializers.
BUG=v8:1859
Review URL: https://chromiumcodereview.appspot.com/9666052
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11010 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is necessary in order to link v8_shell (for host) with the Android
toolchain.
Without it, the line in the makefile is:
$(builddir)/v8_shell: LD_INPUTS := $(OBJS) $(obj).host/v8/tools/gyp/libv8_snapshot.a $(obj).host/v8/tools/gyp/libv8_base.a
Now it appears as:
$(builddir)/v8_shell: LD_INPUTS := $(OBJS) $(obj).host/v8/tools/gyp/libv8_base.a $(obj).host/v8/tools/gyp/libv8_snapshot.a
and it successfully links.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/9668013
Patch from Yaron Friedman <yfriedman@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11005 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
All module expressions, and all variables that might refer to modules,
are assigned interfaces (module types) that are resolved using
unification. This is necessary to deal with the highly recursive
nature of ES6 modules, which does not allow any kind of bottom-up
strategy for resolving module names and paths.
Error messages are rudimental right now. Probably need to track
more information to make them nicer.
R=svenpanne@chromium.org
BUG=v8:1569
TEST=
Review URL: https://chromiumcodereview.appspot.com/9615009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10966 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
