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

David Chisnall
Sat, 10 Aug 2013 09:58:27 -0000

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