Fix bounds check for slicesx.Get

[emcfarlane]

This changes slicesx.Get and slicesx.GetPointer to check the idx is within the length of the slice not the capacity. This avoids accessing slice data that is outside the slice length, allowing the use of slicesx.Get as a bonds check for indexing into a slice.

[jhump]

I think the point of this was to allow accessing any element in the underlying backing array. Though I suppose we could apply this change and then update other callers that might rely on the old behavior to pass in slice[:cap(slice)].

I'll let @mcy make the call on this one.

[emcfarlane]

@jhump this was based on the comment here: #429 (comment)
For this to replace the current behaviour it has to be len, I'm also not sure when this would be useful otherwise as the original slice header isn't mutated to include the possible out of length value. What is a valid use case for cap?

[jhump]

Thinking a little more, maybe this is the right change. I guess this was really meant to elide a bounds check for accessing a slice: so instead of having to check the length yourself and then reading slice[idx] (which will emit another bounds check in the generated instructions), we can check the bounds only once inside this function and then the caller can examine the bool.

Though, now that I'm thinking about it, is the after-the-fact bool check really cheaper than the before-the-fact range check? I think they both boil down to a cmp followed by jl/jnz...

Edit: Is the bool check maybe cheaper because it doesn't have to (re)load the slice's length?

[mcy]

I think this is the correct change, yes.

Incidentally, I thought I had updated this file with a more efficient version of the bounds check. As Go generates this code, because the compiler is dumb, it generates two branches, even though it can be done with one. Notably, the idx < 0 bit is redundant, because Go guarantees that cap(s) < math.IntMax, and negative values compare as greater than math.IntMax when compared unsigned. When I originally wrote this, I assumed the Go compiler was not dumb and would know it could merge these branches, but I guess I gave it too much credit.

Also I can't immediately remember why I made Get not call GetPointer?

[emcfarlane]

Get not call GetPointer is one less branch.