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

[David Chisnall]

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...