Simplify the compile time feature detection on Arm:
- Define CAN_USE_XXX definitions unconditionally for all target/host
toolchain combinations
- Rename arm_test / ARM_TEST to arm_test_noprob / ARM_TEST_NO_FEATURE_PROBE
- Don't set ARM_TEST_NO_FEATURE_PROBE implicitly on the simulator to make
make simulator / native more consistent
- Unify CpuFeatures::PrintTarget for simulator and native builds
- Remove unecessary CAN_USE_VFP_INSTRUCTIONS definition for android (this is
the default for arm_fpu=default)
- Add a CpuFeatures::Probe() before calling CpuFeatures::PrintFeatures() in PrintHelp
to ensure we have probed features before printing them.
BUG=384474
LOG=N
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/340373002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21935 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Important notices:
- The snapshot cannot be created for big-endian target in cross-compilation
environment on little-endian host using simulator.
- In order to have i18n support working on big-endian target, the icudt46b.dat and
icudt46b_dat.S files should be generated and upstreamed to ICU repo.
- The mjsunit 'nans' test is endian dependent, it is skipped for mips target.
- The zlib and Mandreel from Octane 2.0 benchmark are endian dependent due to
use of typed arrays.
TEST=
BUG=
R=jkummerow@chromium.org, plind44@gmail.com
Review URL: https://codereview.chromium.org/228943009
Patch from Dusan Milosavljevic <Dusan.Milosavljevic@rt-rk.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20778 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The problem is that conditions are evaluated before configuration inheritance is resolved, so we can't just define a configuration like this:
'Optdebug': {
'inherits_from': ['Debug'],
'variables': {
'v8_optimized_debug': 2,
}
}
Instead, we have to put the different settings depending on the optimization level into separate configurations, and use conditions inside the concrete configurations to inherit from the correct base class.
Common settings go in the base configuration DebugBaseCommon, and v8_optimized_debug dependent settings go into DebugBase{0,1,2}
The new Debug configuration inherits from DebugBaseCommon and DebugBase<(v8_optimized_debug), while the new configuration Optdebug inherits from DebugBaseCommon and DebugBase2.
BUG=v8:3252
R=machenbach@chromium.org, jkummerow@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/224443003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20605 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch contains contributions from the following members of the
BlackBerry Web Technologies team:
Eli Fidler <efidler@blackberry.com>
Konrad Piascik <kpiascik@blackberry.com>
Jeff Rogers <jrogers@blackberry.com>
Cosmin Truta <ctruta@blackberry.com>
Peter Wang <peter.wang@torchmobile.com.cn>
Xiaobo Wang <xiaobwang@blackberry.com>
Ming Xie <mxie@blackberry.com>
Leo Yang <leoyang@blackberry.com>
R=bmeurer@chromium.org, jkummerow@chromium.org
Review URL: https://codereview.chromium.org/61153009
Patch from Cosmin Truta <ctruta@blackberry.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18430 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
I sometimes observe broken pipe errors when I run gyp, which causes the gyp
process to fail. This seems to happen if gyp is executed under heavy I/O
pressure.
This change removes the pipes by replacing "echo |" with "< /dev/null".
Technically these are not the same, because "echo |" prints a newline while
"< /dev/null" doesn't, but this difference is not significant in the context of
the commands in toolchain.gypi.
BUG=
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/73623002
Patch from Yuta Kitamura <yutak@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17836 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We recently had some XP issues on chromium.win after https://codereview.chromium.org/19384011/.
This might fix it - quote: "The most likely cause of the problem is a gyp (or similar) change that resulted in v8.dll linking against the release version of the crt (for a debug build). There are two MS VC related files: the crt and the c++ std lib (MSVCR100.DLL and MSVCP100D.DLL). The former is set to release, the latter to debug."
I am not entirely sure if this change fits to the linker options for debug level 2.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/21776002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16026 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch changes the definition of v8_optimized_debug==1 to match the release-mode compiler optimization settings (generally, going from -O1 to -O3 on Linux, similar switches for Mac/Win). This produces a minor speed up on Linux, but significant speedups on Mac and Win. This may make it much harder to debug, though.
It also adds a v8_optimized_debug==2 that, in addition to the compiler optimizations, undef's DEBUG and defines DEBUG. This leaves V8_ENABLE_CHECKS alone (so that the assertions are still enabled), but otherwise basically matches a release mode build.
Builds with v8_optimized_debug==2 roughly match a Release mode build for speed; the V8_ENABLE_CHECKS checks appear to have minimal performance impact (maybe 5-10%, unlike what was previously thought). In addition, switching from the previous optimization settings makes a significant improvement on Mac and Win (50% or more), and switching from DEBUG to NDEBUG makes a significant improvement (another 50% or more).
Note that using v8_optimized_debug==2 may also cause some v8 tests to fail. This is currently is believed to be acceptable.
R=machenbach@chromium.org
BUG=254188
Review URL: https://codereview.chromium.org/19384011
Patch from Dirk Pranke <dpranke@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15937 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
