Mill Computing, Inc. Forums The Mill Tools Compilers LLVM pointers


  • Author
  • nachokb
    Post count: 10
    #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


    • This topic was modified 7 years, 5 months ago by  nachokb.
  • Will_Edwards
    Post count: 98

    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.

  • nachokb
    Post count: 10

    Funny: I thought C would be one of the offenders. After all, basic C syntax exposes pointer arithmetic without any checks (I imagine there *is* a lot of C code out there doing nasty stuff to pointers).

  • Ivan Godard
    Post count: 689

    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.

You must be logged in to reply to this topic.