Added support for assignments to global variables in the toplevel code...

Added support for assignments to global variables in the toplevel code
generator.  We use the normal store IC mechanism with the global
object as the receiver.  The following code is generated for 'x=true'
at toplevel.

======== IA32:

27  mov eax,0xf5d06161          ;; object: 0xf5d06161 <true>
32  mov ecx,0xf5d09c35          ;; object: 0xf5d09c35 <String[1]: x>
37  push [esi+0x17]
40  call StoreIC_Initialize  (0xf5ce75c0)    ;; code: STORE_IC, UNINITIALIZED
45  mov [esp],eax

======== X64:

25  movq rax,0x7f867a7b6199    ;; object: 0x7f867a7b6199 <true>
35  movq rcx,0x7f867a7bae71    ;; object: 0x7f867a7bae71 <String[1]: x>
45  push [rsi+0x2f]
49  call StoreIC_Initialize  (0x7f8655929ac0)    ;; code: STORE_IC, UNINITIALIZED
54  movq [rsp],rax

======== ARM:

32  e59f0054       ldr r0, [pc, #+84]          ;; object: 0xf5b78161 <true>
36  e59f2054       ldr r2, [pc, #+84]          ;; object: 0xf5b7bc35 <String[1]: x>
40  e598c017       ldr ip, [r8, #+23]
44  e52dc004       str ip, [sp, #-4]!
48  e1a0e00f       mov lr, pc
52  e59ff048       ldr pc, [pc, #+72]          ;; debug: statement 0
                                               ;; code: STORE_IC, UNINITIALIZED
56  e58d0000       str r0, [sp, #+0]


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

[Kevin Millikin (Chromium), 2009-10-20 09:43:04]

Erik, take a look at the ARM code please.

[Erik Corry, 2009-10-20 10:55:48]

ARM stuff LGTM.

[William Hesse, 2009-10-20 13:17:49]

LGTM.

http://codereview.chromium.org/305005/diff/1/2
File test/mjsunit/compiler/globals.js (right):

http://codereview.chromium.org/305005/diff/1/2#newcode35
Line 35: 
I think you can call eval('g = 1') again, and the eval cache will run the
previously generated code, testing the IC call's update.  This might be worth
it.

[fschneider, 2009-10-20 13:58:39]

LGTM.

http://codereview.chromium.org/305005/diff/1/3
File src/ia32/fast-codegen-ia32.cc (right):

http://codereview.chromium.org/305005/diff/1/3#newcode184
Line 184: __ pop(eax);
We may avoid a memory access when discarding the result by just doing sth. like 

__ add(esp, 4)

here. However, it uses 3 bytes of space instead of 1.

[Kevin Millikin (Chromium), 2009-10-20 14:08:47]

http://codereview.chromium.org/305005/diff/1/3
File src/ia32/fast-codegen-ia32.cc (right):

http://codereview.chromium.org/305005/diff/1/3#newcode184
Line 184: __ pop(eax);
Yes.  I didn't worry about it because:

Here we're not discarding the result, but the global object left on the stack by
the IC.  We should consider replacing the IC call with a runtime call anyway. 
We should consider making the IC drop the receiver (and take it in a register
anyway).

Ultimately, all real discarded values (of subexpressions) should not ever be
materialized in the first place.