llvm dev - Aug 2013 - [LLVMdev] [global-isel] Random comments on Proposal for a global instruction selector

On Aug 9, 2013, at 2:16 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk> wrote:
> For our back end, we absolutely do not want a type system without pointers
- not only do we have separate registers for pointers, we also have separate
instructions for manipulating them and representing this in SelectionDAG
requires some very ugly hacks. This is also the case for several DSPs, which
have separate address and data registers, and for upcoming Intel chips with MPX
that have 4 hardware bounds registers that need keeping in sync with pointers.
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?

Thanks,
/jakob

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

On Aug 10, 2013, at 2:58 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk> wrote:
> 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.
Yeah, that's probably not a good idea to model as i256.

I would like an extensible system that can do more than just adding pointers to
the type system. I think it should be possible for targets to pre-select
instructions in custom passes. If you know the instruction you want, just insert
it directly. That shouldn't be hard to handle for the target-independent
code.

I also think it would make sense to allow virtual registers that have a register
class instead of an (EVT, Bank) tuple before instruction selection. That would
probably make sense for something like PowerPC condition registers, there is no
reason to invent fake types for that.

If Nuno can pull off a rewriting system with a target-extensible rule set, it
probably wouldn't be too hard to allow custom opaque types either.

Thanks,
/jakob