LLVM pointers

Indeed 🙂

We haven’t really been hampered in our efforts so far because the target code we’ve been focusing on porting and benchmarking is all C and C++, which are memory-unsafe languages. Our event bits, mentioned in the talks, are really helpful for precise GC runtimes. So so far we’ve just ignored it.

But there are precise GC languages using LLVM, and that non-integral pointers are being supported in LLVM is enabling those languages to tell our backend that its storing a pointer and enabling them to make use of our event bits and so on.

C lets you cast a pointer to a particular numeric type (of implementation-defined characteristics), but the only thing it guarantees is that you can cast the numeric back to the original pointer type.

Most machines today with a wider address space do not support address spaces as big as would fit in the size of a pointer. Thus the pointer may be 64 bits, but only the lower 60 bits (in our case; fewer elsewhere) is meaningful. What happens when your pointer arithmetic overflows the meaningful area is not defined by the language, ignored by most hardware, and uncontrollable in LLVM which has removed pointerhood in the front end.

Mill cares about overflow bugs. We want to fault them, and our pointer arithmetic (folded into the LEA op) checks and will throw. The problem is that we can’t generate a LEA from LLVM because LLVM gives us a 64-bit add and the IR cannot represent an actual pointer add, so all we can do is give you an unchecked ADDU. All we can do for now, anyway. We’ll fix LLVM when we get around to it, if nobody else fixes it first. One may hope.