This way we don't clash with the ASSERT* macros
defined by GoogleTest, and we are one step closer
to being able to replace our homegrown base/ with
base/ from Chrome.

R=jochen@chromium.org, svenpanne@chromium.org

Review URL: https://codereview.chromium.org/430503007

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22812 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/426233002

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22709 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

TBR=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/378533002

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22237 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This is a mostly mechanical CL (more than 90% Emacs macros and
query-replace-regexp) moving FILE*/StringStream*-based APIs to
OStream-based APIs. There are a few places where this had to stop,
otherwise the CL would be even bigger, but this can easily and
incrementally cleaned up later.

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/363323003

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22232 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

- this avoids using relative include paths which are forbidden by the style guide
- makes the code more readable since it's clear which header is meant
- allows for starting to use checkdeps

BUG=none
R=jkummerow@chromium.org, danno@chromium.org
LOG=n

Review URL: https://codereview.chromium.org/304153016

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21625 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=svenpanne@chromium.org

Review URL: https://codereview.chromium.org/259183002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21035 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/188543004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19713 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=svenpanne@chromium.org

Review URL: https://codereview.chromium.org/152813006

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19250 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Now stores to inobject fields do no longer prevent hoisting
and combining of loads from other inobject fields.

R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/144423010

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19249 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This reverts commit r19427 for breaking the build. Will reland with
fix.

TBR=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/143203005

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19248 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

Now stores to inobject fields do no longer prevent hoisting
and combining of loads from other inobject fields.

R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/144423010

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19247 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=svenpanne@chromium.org

Review URL: https://codereview.chromium.org/135503004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19213 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=hpayer@chromium.org

Review URL: https://codereview.chromium.org/153563006

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19150 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
R=danno@chromium.org

Review URL: https://codereview.chromium.org/149573014

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19115 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=
R=titzer@chromium.org

Review URL: https://chromiumcodereview.appspot.com/22555004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16139 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

R=svenpanne@chromium.org

Review URL: https://codereview.chromium.org/19272011

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15683 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

The HGlobalValueNumberer class is renamed to HGlobalValueNumberingPhase,
following the naming scheme suggested by danno@chromium.org in
https://codereview.chromium.org/17458002

The GVN phase now uses the phase zone for all its allocations.

Depends upon https://codereview.chromium.org/18022002

R=danno@chromium.org
BUG=

Review URL: https://codereview.chromium.org/17657004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15353 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

There's no need to differentiate between an actual Zone and its
scope. Instead we bind the lifetime of the Zone memory to the
lifetime of the Zone itself, which is way easier to understand
than having to dig through the code looking for zone scopes.

Depends on https://codereview.chromium.org/17826004/

R=danno@chromium.org
BUG=

Review URL: https://codereview.chromium.org/17827005

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15337 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

The phase_zone of CompilationInfo is intended for local allocations that
are freed at the end of the phase.

R=danno@chromium.org
BUG=

Review URL: https://codereview.chromium.org/17573003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15294 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

BUG=

Review URL: https://codereview.chromium.org/16095004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14824 ce2b1a6d-e550-0410-aec6-3dcde31c8c00