[llvm] r306875 - GlobalISel: add G_IMPLICIT_DEF instruction.

[Quentin Colombet via llvm-commits]

> On Jun 30, 2017, at 3:47 PM, Quentin Colombet via llvm-commits <llvm-commits at lists.llvm.org> wrote:
> 
> 
>> 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.

(Sort of not directly related, but long term I want we have only one MachineIRBuilder interface for both GISel and after. Basically, I want we use GISel as a way to clean up/improve the MachineInstrBuilder interface in the process)

>> 
>> 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.
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits