This commit implements nil checks for all platforms. These nil checks
can be optimized on systems with a MMU, but since a major target is
systems without MMU, keep it this way for now.
It implements three checks:
* Nil checks before dereferencing a pointer.
* Nil checks before calculating an address (*ssa.FieldAddr and
*ssa.IndexAddr)
* Nil checks before calling a function pointer.
The first check has by far the biggest impact, with around 5% increase
in code size. The other checks only trigger in only some test cases and
have a minimal impact on code size.
This first nil check is also the one that is easiest to avoid on systems
with MMU, if necessary.
Without this, the following code would not panic:
func getInt(i int) { return i }
make([][1<<18], getInt(1<<18))
Or this code would be allowed to compile for 32-bit systems:
make([][1<<18], 1<<18)
Previously, this would have resulted in a LLVM verification error
because runtime.sliceBoundsCheckMake would not accept 64-bit integers on
these platforms.
This reduces complexity in the compiler without affecting binary sizes
too much.
Cortex-M0: no changes
Linux x64: no changes
WebAssembly: some testcases (calls, coroutines, map) are slightly bigger
* Use 64-bit integers on 64-bit platforms, just like gc and gccgo:
https://golang.org/doc/go1.1#int
* Do not use a separate length type. Instead, use uintptr everywhere a
length is expected.
When doing a slice operation on a slice, use the capacity value instead
of the length. Of course, for strings and arrays, the slice operation
checks the length because there is no capacity. But according to the
spec, this check should be based on cap for slice instead of len:
> For slices, the upper index bound is the slice capacity cap(a) rather
> than the length.
https://golang.org/ref/spec#Slice_expressions
Fixes: https://github.com/aykevl/tinygo/issues/65
It is allowed to index with an int64 even on a 32-bit platform, so we
have to handle that case. But make sure the normal case isn't penalized
by using 32-bit numbers when possible.
This specifically fixes unix alloc(): previously when allocation fails
it would (recursively) call alloc() again to create an interface due to
lacking escape analysis.
Also, all other cases shouldn't try to allocate just because something
bad happens at runtime.
TODO: implement escape analysis.
