[LLVMdev] [global-isel] Random comments on Proposal for a global instruction selector

[David Chisnall]

On 9 Aug 2013, at 22:15, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:

> I am a bit skeptical about the need for pointer types; I don’t think it is the right level of abstraction for an instruction selector. The processors I know about with separate address and data registers (Blackfin, m86k, TriCore) would be modeled perfectly by the register bank labels in the proposal.
> 
> Won’t that work for your case?

It might work, although given that our fat pointers are not integers I'm not sure how you think we should represent them.  We can represent them as i256, but that would be very misleading as they don't have the majority of integer operations defined on them, and we can't materialise a pointer from an integer, only from an existing pointer and an offset.  We ideally want address operations to always be of the form base + offset, where the offset is in an integer register and moves, but the base is not.  Currently, we are generating a lot of increment-base + load sequences and have a pre-RA pass that tries to turn these back into load base+offset instructions.  

Modelling the more complex addressing mode (something like a GEP) directly, and then expanding the ones that can't be expressed with the current target seems cleaner.  

The related issue of the pattern matching in TableGen not being able to cope with multiple valid pointer types is also something I've not seen addressed in your proposal.

I'm also not sure how MPX would be represented in this model, where every pointer has a base and a length in one register set and a cursor in another.   

David