Mill Computing, Inc. › Forums › The Mill › Tools › Compilers › LLVM pointers
Tagged: llvm pointers
- AuthorPosts
- #2777 |
Hey guys,
I remember Ivan’s talk on LLVM and how hard it makes life for a platform where pointers are not strictly integers.
Then I noticed the “Introduce a non-integral pointer type” feature [1] which, while experimental and unstable, seems to be already merged into LLVM (since mid-2016), so I wondered how that would affect your efforts.
My understanding is that this is not _that_ useful *as long as there exist frontends which do not use it* (and use integers for pointers), but maybe you can correct me. Of course, it does provide a way for frontends to be Mill-compatible.
PS. It seems the motivation behind this feature is supporting a JVM-to-LLVM compiler.
Waiting for the next talk/video,
— nachokb
[1] https://reviews.llvm.org/D22488
- This topic was modified 7 years, 9 months ago by nachokb.
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.
- AuthorPosts
You must be logged in to reply to this topic.