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

[Jakob Stoklund Olesen]

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