[llvm] r306875 - GlobalISel: add G_IMPLICIT_DEF instruction.
Quentin Colombet via llvm-commits
llvm-commits at lists.llvm.org
Fri Jun 30 15:47:45 PDT 2017
> 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.
More information about the llvm-commits
mailing list