Add missing StoreIntoObject calls in generated code.

Add missing StoreIntoObject calls in generated code.

Also add StoreIntoSmiField method (for verification purposes).
Only ia32 is implemented for now.

R=iposva@google.com

Committed: https://code.google.com/p/dart/source/detail?r=41607

[Ivan Posva, 2014-10-29 07:58:42]

https://codereview.chromium.org/685003002/diff/1/runtime/vm/stub_code_ia32.cc
File runtime/vm/stub_code_ia32.cc (right):

https://codereview.chromium.org/685003002/diff/1/runtime/vm/stub_code_ia32.cc...
runtime/vm/stub_code_ia32.cc:997: __ StoreIntoObjectNoBarrier(EAX,
Here and other places: In the long run we will need an
InitializeIntoObjectNoBarrier or similar here which does not expect anything
legal to be in the location being stored. These are the initializing stores.

https://codereview.chromium.org/685003002/diff/1/runtime/vm/stub_code_ia32.cc...
runtime/vm/stub_code_ia32.cc:1190: __ StoreIntoObjectNoBarrier(EAX,
ditto here and other places

[koda, 2014-10-29 18:29:21]

https://codereview.chromium.org/685003002/diff/1/runtime/vm/stub_code_ia32.cc
File runtime/vm/stub_code_ia32.cc (right):

https://codereview.chromium.org/685003002/diff/1/runtime/vm/stub_code_ia32.cc...
runtime/vm/stub_code_ia32.cc:997: __ StoreIntoObjectNoBarrier(EAX,
On 2014/10/29 07:58:41, Ivan Posva wrote:
> Here and other places: In the long run we will need an
> InitializeIntoObjectNoBarrier or similar here which does not expect anything
> legal to be in the location being stored. These are the initializing stores.

Yes, I was aware of that, and that also applies to runtime code
(Object::StorePointer et al.).

I decided to wait with the initial/overwrite triage until a future CL because:

a) This CL is correct under the existing generational barrier, since it only
cares about object alignment

b) This CL will continue to be correct when adding the Verify calls for
StorePointer, since my plan is to Accept the entire area of newly allocated
objects. (Thus we'll verify illegal == illegal.)

The next steps would then be:

1. Start verifying that StoreSmi overwrites a Smi, and use the failures to
correctly distinguish initializing stores from overwrites.

2. Distinguish initializing pointer stores (can do this by looking for the zap
word).

If you insist, I can create the methods now (as simple forwarders), and do an
incomplete triage.

[koda, 2014-11-05 23:01:42]

On 2014/10/29 18:29:21, koda wrote:
> https://codereview.chromium.org/685003002/diff/1/runtime/vm/stub_code_ia32.cc
> File runtime/vm/stub_code_ia32.cc (right):
> 
>
https://codereview.chromium.org/685003002/diff/1/runtime/vm/stub_code_ia32.cc...
> runtime/vm/stub_code_ia32.cc:997: __ StoreIntoObjectNoBarrier(EAX,
> On 2014/10/29 07:58:41, Ivan Posva wrote:
> > Here and other places: In the long run we will need an
> > InitializeIntoObjectNoBarrier or similar here which does not expect anything
> > legal to be in the location being stored. These are the initializing stores.
> 
> Yes, I was aware of that, and that also applies to runtime code
> (Object::StorePointer et al.).
> 
> I decided to wait with the initial/overwrite triage until a future CL because:
> 
> a) This CL is correct under the existing generational barrier, since it only
> cares about object alignment
> 
> b) This CL will continue to be correct when adding the Verify calls for
> StorePointer, since my plan is to Accept the entire area of newly allocated
> objects. (Thus we'll verify illegal == illegal.)
> 
> The next steps would then be:
> 
> 1. Start verifying that StoreSmi overwrites a Smi, and use the failures to
> correctly distinguish initializing stores from overwrites.
> 
> 2. Distinguish initializing pointer stores (can do this by looking for the zap
> word).
> 
> If you insist, I can create the methods now (as simple forwarders), and do an
> incomplete triage.

Ping.

[Ivan Posva, 2014-11-07 01:58:42]

LGTM -ip

[koda, 2014-11-07 17:17:46]

Committed patchset #2 (id:20001) manually as r41607 (presubmit successful).