Use nearlabel AFAP in lithium codegen

Use nearlabel AFAP in lithium codegen

BUG=
R=jkummerow@chromium.org

Committed: http://code.google.com/p/v8/source/detail?r=17583

[Jakob Kummerow, 2013-10-28 10:37:19]

The MacroAssembler::CheckMap cleanup looks good.

I'm more concerned about using Label::kNear everywhere. yangguo@ has tried that
before, and surprisingly saw slight performance losses instead of the expected
improvements. Are you seeing improvements? Have you made sure there are no
regressions?

Also, with one of the changes you're reintroducing a bug (see comment below).

https://codereview.chromium.org/47533002/diff/1/src/ia32/lithium-codegen-ia32.cc
File src/ia32/lithium-codegen-ia32.cc (left):

https://codereview.chromium.org/47533002/diff/1/src/ia32/lithium-codegen-ia32...
src/ia32/lithium-codegen-ia32.cc:3610: __ j(not_equal, &receiver_ok);  // A near
jump is not sufficient here!
Why do you think this comment is not true anymore?

[Weiliang, 2013-10-28 14:31:49]

Addressed comments

The performance data on my Core2/Linux platform
Core2-IA32	Kraken	SunSpider	Octane
orig	      1798.0ms	227.5ms 	16024
opt	      1793.4ms	226.9ms	        16029
			
Core2-x64	Kraken	SunSpider	Octane
orig	       1745.3ms	227.1ms	       15103
opt	       1743.1ms	227.1ms	       15144

Some workloads has slightly improvement (especially for kraken-ia32, the
beat-detection is improved from 211.6ms  to  206.9ms)and no regression.

https://codereview.chromium.org/47533002/diff/1/src/ia32/lithium-codegen-ia32.cc
File src/ia32/lithium-codegen-ia32.cc (left):

https://codereview.chromium.org/47533002/diff/1/src/ia32/lithium-codegen-ia32...
src/ia32/lithium-codegen-ia32.cc:3610: __ j(not_equal, &receiver_ok);  // A near
jump is not sufficient here!
On 2013/10/28 10:37:19, Jakob wrote:
> Why do you think this comment is not true anymore?

Yes, thanks for pointing it out. near jump is not sufficient here due to
deopt-n-times flags. 

Seems current test does not find out this bug

[Jakob Kummerow, 2013-10-31 10:30:44]

LGTM. I'll land when the tree is open again.


On 2013/10/28 14:31:49, Weiliang wrote:
> Seems current test does not find out this bug

They do if you run with --deopt-every-n-times ;-)

[Jakob Kummerow, 2013-11-06 16:42:16]

Wanted to land this, but I'm still getting ASSERT failures with:

tools/run-tests.py --arch ia32 --mode debug --extra-flags="--deopt-every-n-times
1000000"

[Jakob Kummerow, 2013-11-06 17:02:19]

...and even more failures on x64.

[Jakob Kummerow, 2013-11-06 17:04:24]

On 2013/11/06 17:02:19, Jakob wrote:
> ...and even more failures on x64.

Scratch that, x64 doesn't support --deopt-every-n-times. Which makes me nervous
about the number of invalid near jumps that will be exposed once we support
that.

[Weiliang, 2013-11-07 05:17:03]

On 2013/11/06 16:42:16, Jakob wrote:
> Wanted to land this, but I'm still getting ASSERT failures with:
> 
> tools/run-tests.py --arch ia32 --mode debug
--extra-flags="--deopt-every-n-times
> 1000000"

Fixed, please see the patch set3

[Weiliang, 2013-11-07 05:35:16]

On 2013/11/07 05:17:03, Weiliang wrote:
> On 2013/11/06 16:42:16, Jakob wrote:
> > Wanted to land this, but I'm still getting ASSERT failures with:
> > 
> > tools/run-tests.py --arch ia32 --mode debug
> --extra-flags="--deopt-every-n-times
> > 1000000"
> 
> Fixed, please see the patch set3

Actually assert-opt-and-deopt.js fails when running debug test with
--deopt-devery-n-times, but it does not caused by this CL. 

BTW, what is the deopt-every-n-times for? Is it necessary to support it in X64?

[Weiliang, 2013-11-08 04:32:11]

On 2013/11/06 17:04:24, Jakob wrote:
> On 2013/11/06 17:02:19, Jakob wrote:
> > ...and even more failures on x64.
> 
> Scratch that, x64 doesn't support --deopt-every-n-times. Which makes me
nervous
> about the number of invalid near jumps that will be exposed once we support
> that.

patch set 4 fixed the assert fails exposed by supporting --deopt-every-n-times
in x64.

[Jakob Kummerow, 2013-11-08 10:50:55]

LGTM, landing.

[Jakob Kummerow, 2013-11-08 10:52:41]

Committed patchset #4 manually as r17583 (presubmit successful).