More code for ia32, more shared code.

More code for ia32, more shared code.

CreateArrayComp, EqualityCompareComp, StoreStaticField, LoadStaticField, StoreIndexedComp, StoreInstanceFieldComp, Throw, Rethrow, AssertBooleanComp.
Made more code shared, which has the disadvantage od splitting MakeLocationSummary from EmitNativeCode. Discuss.
Committed: https://code.google.com/p/dart/source/detail?r=8343

[Florian Schneider, 2012-06-06 10:55:18]

On 2012/06/05 23:38:29, srdjan wrote:

Maybe it is ok to have the templates duplicated for the different platforms as
long as they are small enough. It is a one-time effort. The shorter templates
likely won't change much afterwards and for future platforms we may have to
factor them out into platform-specific files again (e.g. ARM) 

For larger instruction templates I agree that the best way would be to split
them up at the flow-graph level if possible.

[Florian Schneider, 2012-06-06 14:23:52]

LGTM.

As I said, I'm not sure if it is worth sharing code between platforms just yet,
but I'm fine with landing this to see how it works out in the future.

[srdjan, 2012-06-06 14:54:33]

On 2012/06/06 14:23:52, Florian Schneider wrote:
> LGTM.
> 
> As I said, I'm not sure if it is worth sharing code between platforms just
yet,
> but I'm fine with landing this to see how it works out in the future.

Thanks. I am in doubt myself and will therefore unshare the code, so that it is
easier viewable, and once we start adding optimization it may make sense anyway.

[srdjan, 2012-06-06 15:32:20]

On 2012/06/06 14:54:33, srdjan wrote:
> On 2012/06/06 14:23:52, Florian Schneider wrote:
> > LGTM.
> > 
> > As I said, I'm not sure if it is worth sharing code between platforms just
> yet,
> > but I'm fine with landing this to see how it works out in the future.
> 
> Thanks. I am in doubt myself and will therefore unshare the code, so that it
is
> easier viewable, and once we start adding optimization it may make sense
anyway.

And talked with Slava ... going with what is now in the CL (no unsharing again),
and if feel being hurt by the sharing, I can unshare in a following CL.

I understand both Florian's and Slava's points.

[Ivan Posva, 2012-06-07 06:54:27]

In my experience sharing assembly code is a losing proposition. The amount of
shared code when adding more than two CPU targets is negligible and the
intersection tends towards zero so that the overhead of trying to maintain
sharing is actually more cost than a benefit.

I did add a few specific comments below. Which should high-light my point that
this is probably working fine for ia32 and x64, but will fall flat when trying
to add ARM or anything else.

-Ivan

https://chromiumcodereview.appspot.com/10543013/diff/2003/runtime/vm/intermed...
File runtime/vm/intermediate_language.cc (right):

https://chromiumcodereview.appspot.com/10543013/diff/2003/runtime/vm/intermed...
runtime/vm/intermediate_language.cc:662: __ int3();
How can this be shared code?

https://chromiumcodereview.appspot.com/10543013/diff/2003/runtime/vm/intermed...
runtime/vm/intermediate_language.cc:680: __ int3();
ditto!

https://chromiumcodereview.appspot.com/10543013/diff/2003/runtime/vm/intermed...
runtime/vm/intermediate_language.cc:699: __ j(EQUAL,
compiler->GetBlockLabel(true_successor()));
This is definitely not a portable assembler instruction.

https://chromiumcodereview.appspot.com/10543013/diff/2003/runtime/vm/intermed...
runtime/vm/intermediate_language.cc:715: __ MoveRegister(locs()->out().reg(),
CTX);
CTX sounds like a very CPU-specific register to me.