[llvm] r306875 - GlobalISel: add G_IMPLICIT_DEF instruction.
Quentin Colombet via llvm-commits
llvm-commits at lists.llvm.org
Fri Jun 30 15:29:57 PDT 2017
> On Jun 30, 2017, at 2:32 PM, Tim Northover <tnorthover at apple.com> wrote:
>
> On 30 Jun 2017, at 14:09, Quentin Colombet <qcolombet at apple.com> wrote:
>> Should we add an actual opcode?
>> Put differently are we going to treat G_IMPLICIT_DEF and IMPLICIT_DEF differently?
>
>> I believe this only gets us the isPreISelxxx helper for “free”. But if that’s the only thing, I would argue we can fix isPreISelxxx to be smarter about those. Anyhow, I think it needs to be discussed.
>
> The data structures in the legalization table would have to change too since the array only has enough room for G_* nodes, but that's an implementation detail (I'd gone most of the way through doing that before deciding it was a hack and switching to G_IMPLICIT_DEF).
>
> I think having the instructions that take part in the generic type system tagged is pretty useful. It draws a clear line between what's been selected and what's still under question.
>
>> Note: The reason why I am not fond of this change is because if we start in that direction, I believe we will have to add others like COPY and I want to make sure this is the right design before. Right now, I am not convince.
>
> I'd certainly be open to doing that. COPY's overloaded meaning meant that until just this week quite a few were actually various kinds of cast in disguise.
>
> I don't think that would have happened if we'd had a G_COPY which we'd seriously considered as a GIsel concept from the beginning.
Exactly, but then we decided against it, so that’s why I am surprised we go back to that now.
> 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. Don’t take me wrong, it may be the right thing to do, however right now, I am seeing the advantages you are mentioning with the clearer line and such, but the cost is unclear to me and potentially too high. In particular, should G_COPY returns true to MachineInstr::isCopy, ditto for G_IMPLICIT_DEF with MachineInstr::isImplicitDef? When do we use G_PHI vs PHI (e.g., in the MachineIRBuilder interface)?
>
> So actually I think the case for doing it to COPY is even more compelling.
>
> Cheers.
>
> Tim.
More information about the llvm-commits
mailing list