[llvm] r306875 - GlobalISel: add G_IMPLICIT_DEF instruction.

[Quentin Colombet via llvm-commits]

> On Jun 30, 2017, at 3:43 PM, Tim Northover <tnorthover at apple.com> wrote:
> 
>> 
>>> In fact I think it would have been enforced by the MachineVerifier.
>>> 
>>> Also, while an IMPLICIT_DEF basically disappears, a COPY eventually becomes a real instruction. Or in case of a G_COPY potentially lots of instructions.
>> 
>> That all sound like implementation details of the legalizer.
> 
> I don't think enforcing type-consistency is an implementation detail, or confined to the legalizer.

I agree that enforcing type-consistency is not an implementation detail. What I am saying is that it does not need to be tight to new G_ opcodes.
Again, what can we do with that additional opcode that we couldn’t without.

> The other is resolved by the legalizer[*] but a question relevant in any stage before that too.
> 
>> In particular, should G_COPY returns true to MachineInstr::isCopy, ditto for G_IMPLICIT_DEF with MachineInstr::isImplicitDef?
> 
> I'm not sure it matters until we start dealing with combines properly. And even then G_* is going to be entirely contained in GISel code so we can pick whichever is more convenient for us at the time.

Well, that’s already a problem if you want to use for instance getFirstNonPHI. I.e., GISel specific is going to “leak" outside of GISel domain per say.

> 
>> When do we use G_PHI vs PHI (e.g., in the MachineIRBuilder interface)?
> 
> I'd make MachineIRBuilder always emit the G_* instructions because its designed to be the generic MIR builder in all other cases. This makes its behaviour more consistent again.
> 
> Cheers.
> 
> Tim.
> 
> [*] Though even then maybe only because we're being a bit naive right now. When 512-bit types are flying around more regularly because QQQQ is a valid type for stores RegBankSelect and ISel might end up getting in on the fun too.

I didn’t get that comment.