[stdlib] Optimize normalize_index for unsigned types

[yinonburgansky]

Use the Indexer trait in normalize_index to optimize for UInt, UInt8, UInt16, UInt32, and UInt64 types.

[yinonburgansky]

As a side note:
Currently there is an implicit casting between UInt and Int:

fn main():
    # binary operators use the method of left side type
    print(Int(-1) < UInt(1<<63)) # False 
    print(UInt(1<<63) > Int(-1)) # False
    print(UInt(1) > Int(-1)) # False
    print(Int(-1) < UInt(1)) # True

[yinonburgansky]

I've found out that by doing the bounds check after the index normalization we can avoid a comparison
and support negative indexing up to UInt.MAX in a performant way.
The compiler is smart enough to optimize the index normalization into branchless index += (index >> 63) & len and the bounds check for Int and UInt are the same.
so the only cost of using negative indexing now is just a few ALU operations.

This is also True for SIMD so if needed we can add support UInt8.MAX sized containers and use negative Int8 indexes without upcasting or doing more expensive bounds check, the only cost is the normalization which can be done branchless.

See https://godbolt.org/z/nMhz6dWhh

[owenhilyard]

This long chain of type comparisons makes me thing we want an UnsignedInteger trait. However, I'd like to see a bounds check that UInt is large enough, ideally a fast path at compile time using .MAX and a slower path at runtime. UInt is large enough for all values right now, so this is a forward-looking change for UInt128 and UInt256 (which cryptography wants).

[yinonburgansky]

added a compile time check for sizeof index <= sizeof length.

[yinonburgansky]

removed the check since it is wrong, since a big size struct can implement the Indexer trait and return a single property as the index.
By the definition of the current indexer trait it has to be convertible to mlir_index which represent the hardware width integer, so currently we can't really have UInt128 index in 64bit hardware.

[owenhilyard]

This cast should remove values < 0, so the next check is always true.

[yinonburgansky]

This does a bitcast to control where we do Signed/Unsigned comparison in the following code.
On the hardware it uses base 2 complement, so addition is the same for signed and unsigned, but comparison is different. It does work, see the unit tests.
I added an intermediate mlir_index to make it more clear.

[owenhilyard]

length should probably be a UInt in most cases. I can't think of many reasons to have it be and using Int for length gets rid of a lot of address space.

[yinonburgansky]

So currently there is an implicit cast between Int and UInt and you have to be very careful when mixing them (see example in the comment above for what can go wrong)
The rational for adding another variant is to make working with UInt or Int a decision for the user, the returned index type will be the same as the user container length type.
This open the possibility for SIMD sized container e.g. UInt8 sized container should get back UInt8 type index.
Since currently all stdlib containers are Int sized, we need the Int variant.