Fix allocation of array tables (use store barrier if needed, store values directly instead of via s…

Fix allocation of array tables (use store barrier if needed, store values directly instead of via stack).
Committed: https://code.google.com/p/dart/source/detail?r=18464

[hausner, 2013-02-13 00:47:29]

I would prefer if you didn't have to allocate a temp variable in each function,
whether it's needed or not. See comment below.

https://codereview.chromium.org/12212050/diff/8032/runtime/vm/parser.cc
File runtime/vm/parser.cc (right):

https://codereview.chromium.org/12212050/diff/8032/runtime/vm/parser.cc#newco...
runtime/vm/parser.cc:768: parsed_function->set_array_literal_var(
I don't like that you have to allocate a variable for each function, whether
it's used by the backend or not. It is needed in very few cases.

Could you not keep the old behavior of the ArrayNode if there is no temporary
variable given to the ArrayNode? That way, you treat all cases where the array
node is allocated in the parser with your new code generation pattern, and the
one use where the array node is allocated in the backend, code generation
remains as it is now.

[hausner, 2013-02-13 01:11:19]

Ok, LGTM after offline discussion. But I still don't like it :)

[srdjan, 2013-02-13 01:15:00]

https://codereview.chromium.org/12212050/diff/8032/runtime/vm/parser.cc
File runtime/vm/parser.cc (right):

https://codereview.chromium.org/12212050/diff/8032/runtime/vm/parser.cc#newco...
runtime/vm/parser.cc:768: parsed_function->set_array_literal_var(
On 2013/02/13 00:47:30, hausner wrote:
> I don't like that you have to allocate a variable for each function, whether
> it's used by the backend or not. It is needed in very few cases.
> 
> Could you not keep the old behavior of the ArrayNode if there is no temporary
> variable given to the ArrayNode? That way, you treat all cases where the array
> node is allocated in the parser with your new code generation pattern, and the
> one use where the array node is allocated in the backend, code generation
> remains as it is now.

I don't like it either, but could not come up with a solution that would avoid
it (discussed offline). Optimized code will get rid of it.