Something to note: by using / the Int.__truediv__(Int) function is called which converts both values to floats and then returns a float which we manually cast back to an Int. I believe you can avoid the int -> conversions completely by using the index.divs operation.

Looking at the llvm ir output here we can avoid the fp <-> si conversions.

Thanks for the insight, Nathan! From what I’ve read, Mojo lowers through MLIR before LLVM, and MLIR already exposes the divs (signed) and divu (unsigned) ops for integer division. Would it make sense here to call that directly instead of using /?

Something along the lines of:

var element_size = sizeof[T]()
var byte_diff = self.address - other.address
return intrinsics.divs(byte_diff, element_size)

That way we’d avoid the intermediate float conversion in the generated LLVM IR, and stay closer to the “raw” integer semantics. Curious if you think that’s overkill compared to keeping / for readability.

Correct, we can directly use the

__mlir_op.`index.divs`(element_size.value, byte_diff.value)

@lattner also mentions the LLVM sdiv exact instruction however, I'm unsure how we are able to convert the __mlir_type.index to a type that plays nicely with the llvm instruction. (I was looking at the arith.index_cast mlir dialect but I don't think we have access that that yet).

What's the reason for restricting the self type here?

Good point, will remove that

There isn't a cast free function in this module, which is why CI is failing. Also note that we already have a __sub__ overload that works for Indexer instances; can we delegate to that (or the other way around)?

Hmm, not sure how that would work though? I switched this to use builtin.ptrtoint since that seems to be the right way to handle pointer-to-int conversion here.

Also, there is an issue with my local environment so I am having to commit changes in order to test them, hence the delays.