Refactor _ByteDataView.[set|get]* methods to improve their performance.

Refactor _ByteDataView.[set|get]<Type> methods to improve their performance.

- don't manually truncate values before passing them to TypedData._[set|get]<Type> - these methods already have truncating semantics;

- don't call into runtime for endianess conversion, implement it in pure Dart instead (with an intent to provide optimized version on platforms that support fast byte-swapping instructions);

- force inlining of these methods (change the order of checks in the ShouldWeInline to guarantee inlining of whitelisted methods).

Unrelated change:

- tweak output of Function::CheckSourceFingerprint to be immediately copy&paste useful.

R=fschneider@google.com
BUG=http://dartbug.com/22107

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

[Vyacheslav Egorov (Google), 2015-01-20 23:31:26]

PTAL. 

Local benchmarking (ia32):

Write (BE)(RunTime): 63156.25 us.
Write (LE)(RunTime): 9081.447963800905 us.
Write (HE)(RunTime): 18376.146788990827 us.
Read (BE)(RunTime): 54270.27027027027 us.
Read (LE)(RunTime): 4943.20987654321 us.
Read (HE)(RunTime): 12395.061728395061 us.

Write (BE)(RunTime): 10928.96174863388 us. (6x improvement)
Write (LE)(RunTime): 7956.349206349207 us.
Write (HE)(RunTime): 9448.11320754717 us. (2x improvement)
Read (BE)(RunTime): 7260.869565217391 us. (7x improvement)
Read (LE)(RunTime): 4350.0 us.
Read (HE)(RunTime): 4270.7889125799575 us. (3x improvement)

There are some unfortunate corner cases however related to the use of typed data
views for endianess conversion - it is very easy to poison type feedback for the
methods of the view class (e.g. if you use somewhere new Float64List.view(new
Uint8List(8)) and somewhere else new Float64List.view(new Uint32List(2)) - this
really degrades the quality of the code produced from []/[]= for reasons not
entirely obvious to me). We need to discuss this separately.

My benchmark also does not cover some special cases: Int32 values outside of Smi
range, Int64 values. I will check that we have good performance for these cases
as well.

[Florian Schneider, 2015-01-21 09:34:38]

LGTM.

https://codereview.chromium.org/860963002/diff/1/runtime/lib/typed_data.dart
File runtime/lib/typed_data.dart (right):

https://codereview.chromium.org/860963002/diff/1/runtime/lib/typed_data.dart#...
runtime/lib/typed_data.dart:3390: final _convU32 = new Uint32List(2);
Once we have allocation sinking for fixed size arrays, we should make these
local variables.

https://codereview.chromium.org/860963002/diff/1/runtime/lib/typed_data.dart#...
runtime/lib/typed_data.dart:3395: _convF32[0] = value;
How about making the view a local variable? If everything is inlined here,
allocation sinking should eliminate the overhead completely and produce even
better code.

https://codereview.chromium.org/860963002/diff/1/runtime/lib/typed_data.dart#...
runtime/lib/typed_data.dart:3397: return _convF32[0];
Does it help to force inline [] and []= on typed data views as well?

https://codereview.chromium.org/860963002/diff/1/runtime/lib/typed_data.dart#...
runtime/lib/typed_data.dart:3401: _convF64[0] = value;
Same for the view object here.

[Vyacheslav Egorov (Google), 2015-01-21 12:17:56]

Thanks for the review!

https://codereview.chromium.org/860963002/diff/1/runtime/lib/typed_data.dart
File runtime/lib/typed_data.dart (right):

https://codereview.chromium.org/860963002/diff/1/runtime/lib/typed_data.dart#...
runtime/lib/typed_data.dart:3390: final _convU32 = new Uint32List(2);
On 2015/01/21 09:34:38, Florian Schneider wrote:
> Once we have allocation sinking for fixed size arrays, we should make these
> local variables.

Our load forwarding only supports forwarding for loads&stores typed in the same
way. Here we have a memory location that is written through one type and loaded
through another type. We don't support this and I am not sure it is worth the
trouble to support it.

In fact I realized: I need to check if we even account for possibility of such
aliasing in our algorithm

https://codereview.chromium.org/860963002/diff/1/runtime/lib/typed_data.dart#...
runtime/lib/typed_data.dart:3395: _convF32[0] = value;
On 2015/01/21 09:34:38, Florian Schneider wrote:
> How about making the view a local variable? If everything is inlined here,
> allocation sinking should eliminate the overhead completely and produce even
> better code.

See above. We are not powerful enough yet.

https://codereview.chromium.org/860963002/diff/1/runtime/lib/typed_data.dart#...
runtime/lib/typed_data.dart:3397: return _convF32[0];
On 2015/01/21 09:34:38, Florian Schneider wrote:
> Does it help to force inline [] and []= on typed data views as well?

They are inlined here. However if we have polymorphism inside []/[]= - we first
inline polymorphically and then eliminate one possibility - but LICM and GVN are
blocked by redifinitons. We should discuss this separately.

https://codereview.chromium.org/860963002/diff/1/runtime/lib/typed_data.dart#...
runtime/lib/typed_data.dart:3401: _convF64[0] = value;
On 2015/01/21 09:34:38, Florian Schneider wrote:
> Same for the view object here.

See above for the reasons why it is global.

[Vyacheslav Egorov (Google), 2015-01-21 14:21:58]

Committed patchset #1 (id:1) manually as 43038 (presubmit successful).