Define size more explicitly, helping the compiler

[c42f]

@Keno this is an updated version of your PR.

Resolves #137

[coveralls]

Coverage increased (+0.1%) to 69.918% when pulling 01eb1f1 on size-optimization into 4d74ac7 on master.

[andyferris]

@Keno @c42f could we please confirm that these changes make a positive impact on generated code given recent merged PRs? (I haven't looked but the spirit here seems ok by me).

[andyferris]

Is generated code better with Size(t)?

[c42f]

Yep, it's better. I didn't spend a lot of time on this, but I did check the the following using @Keno's original example:

Without patch:

julia> foo(A) = size(A,2)
julia> @code_llvm foo(ones(SMatrix{2,3}))

define i64 @julia_foo_60424(%SArray* nocapture readonly dereferenceable(48)) #0 !dbg !5 {
top:
  %1 = call i64 @julia_size_60425(%SArray* nocapture nonnull readonly %0, i64 2)
  ret i64 %1
}

With patch:

julia> foo(A) = size(A,2)
julia> @code_llvm foo(ones(SMatrix{2,3}))

define i64 @julia_foo_60360(%SArray* nocapture readonly dereferenceable(48)) #0 !dbg !5 {
top:
  ret i64 3
}

It'll be a bit of a grind, but we need to put some solid work into benchmarking StaticArrays. This kind of spot checking of the assembly is all very well, but I'm pretty sure we're going to fall into a massive performance hole sometime soon without realizing it :-/

[c42f]

I checked a few other things like bar(A) = size(A)[1] + size(A)[2] - all looks good afaict.

[coveralls]

Coverage decreased (-0.1%) to 70.54% when pulling 26a9db2 on size-optimization into 2a09e2c on master.

[Keno]

This looks fine to me.

[andyferris]

Thanks guys!!