[PATCH] D22008: GlobalISel: implement low-level type suitable for MachineInstr selection

[Quentin Colombet via llvm-commits]

Hi Tim,
> On Jul 6, 2016, at 10:05 AM, Tim Northover <t.p.northover at gmail.com> wrote:
> 
> On 5 July 2016 at 14:43, Quentin Colombet <qcolombet at apple.com> wrote:
>>> I suppose we could add some concept of a generic MachineInstr's "realm" (int/float) to provide the dropped info?
>> 
>> Yeah, that is what I was going to say, the generic code will know if something is floating point or int. That’s probably something we will need at some point elsewhere and we could have that live as a query function like isPreISelOpcode.
> 
> If we really think we're going to need that information then I'm not
> sure stripping the types down to just a size is the right path after
> all. We're going to run into the same ambiguity as for the types
> themselves where each operand can have a separate domain (e.g. sitofp,
> intrinsics again).

I don’t see why this is a problem. The instruction is typed not the registers and actually we always used the instruction opcode as a discriminant (e.g., fadd vs. add) even if this is redundant at the IR level. I think we have the opportunity to kill that redundancy and, for consistency with IR, I’d like we keep the domain on the opcode.

> 
> At that point we'd essentially just have the type distributed across 2
> tables rather than in one place.

Except that I think this information is only needed to bootstrap a new backend. Essentially, the reason why I need it in RegisterBankInfo is to avoid the target to write code (like you had to in that patch). Then, as the framework progress (tablegen in particular), I expect that we would drop this support.

The bottom line is, this is for a smoother transition from SDISel to GISel than actually needed for GISel.

Cheers,
-Quentin 

> 
> Tim.