Strict mode fixes.

Strict mode fixes.
- mutual inlining strict and non-strict functions in crankshaft.
- assignment to undefined variable with eval in scope.
- propagation of strict mode through lazy compilation.

BUG=
TEST=test/mjsunit/strict-mode.js test/mjsunit/strict-mode-opt.js

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

[Martin Maly, 2011-04-07 10:07:07]

http://codereview.chromium.org/6814012/diff/1/src/arm/lithium-codegen-arm.cc
File src/arm/lithium-codegen-arm.cc (right):

http://codereview.chromium.org/6814012/diff/1/src/arm/lithium-codegen-arm.cc#...
src/arm/lithium-codegen-arm.cc:2220: Handle<Code> ic = instr->strict_mode()
First fix. When optimizing strict mode functions we always used StoreIC instead
of its strict counterpart.

http://codereview.chromium.org/6814012/diff/1/src/arm/lithium-codegen-arm.cc#...
src/arm/lithium-codegen-arm.cc:3076: Handle<Code> ic = instr->strict_mode()
Second fix - the info_ does contain strict mode flag, but it belongs to the
optimized function. If we are inlining strict function in non-strict or vice
versa we need strict mode of the function being inlined. Hydrogen stores the
strict mode of the inlined function into the instructions so we can use it here.

http://codereview.chromium.org/6814012/diff/1/src/ast.h
File src/ast.h (left):

http://codereview.chromium.org/6814012/diff/1/src/ast.h#oldcode1788
src/ast.h:1788: bool strict_mode_;
Unused :( I moved it to scope and didn't remove from here. Oops.

http://codereview.chromium.org/6814012/diff/1/src/compiler.cc
File src/compiler.cc (right):

http://codereview.chromium.org/6814012/diff/1/src/compiler.cc#newcode606
src/compiler.cc:606: 
Third fix. SharedFunctionInfo of lazy compiled functions is not fully pupulated
(since we haven't yet parsed) so here, after parse, we need to remember more
data on the shared info and CompilationInfo.

http://codereview.chromium.org/6814012/diff/1/src/runtime.cc
File src/runtime.cc (right):

http://codereview.chromium.org/6814012/diff/1/src/runtime.cc#newcode7825
src/runtime.cc:7825: 
Fourth fix. If eval is in scope, runtime call is used for assignment to
variables. If assignment should result in adding property to global object, in
strict mode we must throw.

[Lasse Reichstein, 2011-04-08 12:54:18]

LGTM

http://codereview.chromium.org/6814012/diff/1/src/compiler.cc
File src/compiler.cc (right):

http://codereview.chromium.org/6814012/diff/1/src/compiler.cc#newcode606
src/compiler.cc:606: 
The preparser should be able to detect this and store it in the preparser data
with the other data that are set for lazy functions.
On the other hand, if this is sufficient, I guess it'll do.

http://codereview.chromium.org/6814012/diff/1/test/mjsunit/strict-mode-opt.js
File test/mjsunit/strict-mode-opt.js (right):

http://codereview.chromium.org/6814012/diff/1/test/mjsunit/strict-mode-opt.js...
test/mjsunit/strict-mode-opt.js:29: var MAX = 10000000;
That's a lot. Is it really necessary?
Are there any flags you could use to make optimization more frequent so you
don't need as big a loop?

[Lasse Reichstein, 2011-04-08 12:54:19]

LGTM

[Martin Maly, 2011-04-08 14:27:39]

Thanks, Lasse.

http://codereview.chromium.org/6814012/diff/1/src/compiler.cc
File src/compiler.cc (right):

http://codereview.chromium.org/6814012/diff/1/src/compiler.cc#newcode606
src/compiler.cc:606: 
On 2011/04/08 12:54:18, Lasse Reichstein wrote:
> The preparser should be able to detect this and store it in the preparser data
> with the other data that are set for lazy functions.
> On the other hand, if this is sufficient, I guess it'll do. 

Preparser doesn't yet detect strict mode. Once it does (and it will have to for
early errors) I'll remove this.

http://codereview.chromium.org/6814012/diff/1/test/mjsunit/strict-mode-opt.js
File test/mjsunit/strict-mode-opt.js (right):

http://codereview.chromium.org/6814012/diff/1/test/mjsunit/strict-mode-opt.js...
test/mjsunit/strict-mode-opt.js:29: var MAX = 10000000;
On 2011/04/08 12:54:18, Lasse Reichstein wrote:
> That's a lot. Is it really necessary?
> Are there any flags you could use to make optimization more frequent so you
> don't need as big a loop?

Turns out we inline even with one zero removed so I am taking one zero out for
the landing