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

Jakob Stoklund Olesen
Sun, 11 Aug 2013 04:00:16 -0000

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