Split LoadStatic into two instructions: load static filed, load value.

Split LoadStatic into two instructions: load static field, load value from static field. This allows to canonicalize loads, thus reducing the number of inlined constants. Has large benefit on x64 (DeltaBlue). Note different register allocation spec for ia32, otherwise large regression in DeltaBlue is introduced.

R=fschneider@google.com

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

[srdjan, 2013-06-13 23:07:21]

While x64 benefit is reproducible on my Mac, none is measurable on golem :-( ?!

[Florian Schneider, 2013-06-14 08:55:05]

https://codereview.chromium.org/15973010/diff/52001/runtime/vm/intermediate_l...
File runtime/vm/intermediate_language_ia32.cc (right):

https://codereview.chromium.org/15973010/diff/52001/runtime/vm/intermediate_l...
runtime/vm/intermediate_language_ia32.cc:1768: // generate better code.
Side note: We have a similar issue for LoadField: Ideally, I think we want to
have a policy that allows re-using the input as result, but does not enforce it
(MayUseSameAsFirst)

It may be good to use a different register because of register hints sometimes,
other times re-using the same register saves freeing up another register.

https://codereview.chromium.org/15973010/diff/52001/runtime/vm/intermediate_l...
runtime/vm/intermediate_language_ia32.cc:1777: __ movl(result,
FieldAddress(field, Field::value_offset()));
Do static fields move in memory due to GC?

If not, we could just load from the absolute address directly? This way there is
also no need for an input register and tuning for the best register policy.

[srdjan, 2013-06-14 14:00:04]

https://codereview.chromium.org/15973010/diff/52001/runtime/vm/intermediate_l...
File runtime/vm/intermediate_language_ia32.cc (right):

https://codereview.chromium.org/15973010/diff/52001/runtime/vm/intermediate_l...
runtime/vm/intermediate_language_ia32.cc:1768: // generate better code.
On 2013/06/14 08:55:05, Florian Schneider wrote:
> Side note: We have a similar issue for LoadField: Ideally, I think we want to
> have a policy that allows re-using the input as result, but does not enforce
it
> (MayUseSameAsFirst)
> 
> It may be good to use a different register because of register hints
sometimes,
> other times re-using the same register saves freeing up another register.

Yes, that is a good idea. I think that would help especially ia32 quite a bit.
Next CL.

https://codereview.chromium.org/15973010/diff/52001/runtime/vm/intermediate_l...
runtime/vm/intermediate_language_ia32.cc:1777: __ movl(result,
FieldAddress(field, Field::value_offset()));
On 2013/06/14 08:55:05, Florian Schneider wrote:
> Do static fields move in memory due to GC?
> 
> If not, we could just load from the absolute address directly? This way there
is
> also no need for an input register and tuning for the best register policy.

They don't now, but they will.

[Florian Schneider, 2013-06-14 14:08:58]

lgtm

[Florian Schneider, 2013-06-14 14:09:10]

On 2013/06/14 14:00:04, srdjan wrote:
>
https://codereview.chromium.org/15973010/diff/52001/runtime/vm/intermediate_l...
> File runtime/vm/intermediate_language_ia32.cc (right):
> 
>
https://codereview.chromium.org/15973010/diff/52001/runtime/vm/intermediate_l...
> runtime/vm/intermediate_language_ia32.cc:1768: // generate better code.
> On 2013/06/14 08:55:05, Florian Schneider wrote:
> > Side note: We have a similar issue for LoadField: Ideally, I think we want
to
> > have a policy that allows re-using the input as result, but does not enforce
> it
> > (MayUseSameAsFirst)
> > 
> > It may be good to use a different register because of register hints
> sometimes,
> > other times re-using the same register saves freeing up another register.
> 
> Yes, that is a good idea. I think that would help especially ia32 quite a bit.
> Next CL.
> 
>
https://codereview.chromium.org/15973010/diff/52001/runtime/vm/intermediate_l...
> runtime/vm/intermediate_language_ia32.cc:1777: __ movl(result,
> FieldAddress(field, Field::value_offset()));
> On 2013/06/14 08:55:05, Florian Schneider wrote:
> > Do static fields move in memory due to GC?
> > 
> > If not, we could just load from the absolute address directly? This way
there
> is
> > also no need for an input register and tuning for the best register policy.
> 
> They don't now, but they will.

Is it in the case of a compacting GC? We could still decide to make them
immovable then, couldn't we?

[srdjan, 2013-06-14 14:18:56]

On 2013/06/14 14:09:10, Florian Schneider wrote:
> On 2013/06/14 14:00:04, srdjan wrote:
> >
>
https://codereview.chromium.org/15973010/diff/52001/runtime/vm/intermediate_l...
> > File runtime/vm/intermediate_language_ia32.cc (right):
> > 
> >
>
https://codereview.chromium.org/15973010/diff/52001/runtime/vm/intermediate_l...
> > runtime/vm/intermediate_language_ia32.cc:1768: // generate better code.
> > On 2013/06/14 08:55:05, Florian Schneider wrote:
> > > Side note: We have a similar issue for LoadField: Ideally, I think we want
> to
> > > have a policy that allows re-using the input as result, but does not
enforce
> > it
> > > (MayUseSameAsFirst)
> > > 
> > > It may be good to use a different register because of register hints
> > sometimes,
> > > other times re-using the same register saves freeing up another register.
> > 
> > Yes, that is a good idea. I think that would help especially ia32 quite a
bit.
> > Next CL.
> > 
> >
>
https://codereview.chromium.org/15973010/diff/52001/runtime/vm/intermediate_l...
> > runtime/vm/intermediate_language_ia32.cc:1777: __ movl(result,
> > FieldAddress(field, Field::value_offset()));
> > On 2013/06/14 08:55:05, Florian Schneider wrote:
> > > Do static fields move in memory due to GC?
> > > 
> > > If not, we could just load from the absolute address directly? This way
> there
> > is
> > > also no need for an input register and tuning for the best register
policy.
> > 
> > They don't now, but they will.
> 
> Is it in the case of a compacting GC? We could still decide to make them
> immovable then, couldn't we?

Yes (too all points).

[srdjan, 2013-06-14 18:15:55]

Committed patchset #10 manually as r24044 (presubmit successful).