[LLVMdev] RFC: GEP as canonical form for pointer addressing

David Chisnall
Thu, 20 Feb 2014 09:02:44 -0000

On 20 Feb 2014, at 06:11, Ivan Godard <ivan at ootbcomp.com> wrote:

> It's not just old mainframes, it's some of the newest architecture
as well.
> The Mill general-purpose architecture (http://ootbcomp.com) has non-integer
> pointers and distinct pointer operations too. That LLVM loses pointerhood
is
> the biggest problem that we have identified while looking into using LLVM
as
> our supported compiler. It may be a killer, and we may have to fall back to
> gcc. That would be a shame, but it does appear that the ir makes rash
> assumptions about machine architecture.
>
> "There'd be a lot more work needed to support this" is not
encouraging to
> see, especially for a startup company with limited resources and little
> prior exposure to LLVM internals.

Just to add, I spend a fair bit of my time in the computer architecture research
community, and pointers that are not integers are an increasingly common model.
They simplify various dependency analysis paths in the pipeline (giving fewer
pipeline flushes) and make certain kinds of security features significantly
easier to implement.

Architectures that separate pointers from integers are note becoming rarer.
They are increasingly common in application-specific processors and likely to
reappear in mainstream processors over the next 5-10 years.

We have managed to get LLVM working (and building nontrivial amounts of code) on
a MIPS-derived architecture that has non-integer pointers, and the
representation in the IR itself is fine.  We have a few hacks in optimisations
that are far too coarse grained (i.e. don't do this optimisation if
you're dealing with this kind of pointer, even though many of them [SCEV in
particular] should work but the code makes invalid assumptions).  We do end up
having to add more after every merge.

We start to hit problems when we get to SelectionDAG, which makes a lot of
assumptions about the underlying architecture and has an annoying habit of
thinking it knows better than the back end and undoing transformations that the
back end has done.

David

P.S. The Mill is a very interesting architecture, but I'm very glad I'm
not the one responsible for instruction scheduling on it...