[llvm] r306875 - GlobalISel: add G_IMPLICIT_DEF instruction.

Tim Northover via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 30 16:07:29 PDT 2017


> 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.

Have neat code. Of course we could hack away at the MachineVerifier, Legalizer and whatever else to explain that, no COPY and PHI and IMPLICIT_DEF are special and have this dual role. But I think having G_* variants makes the requirements on each clearer.

>> 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.

I'm afraid I don't get this. You mean that even after GIsel these functions will be checking for G_* nodes that won't exist? I'm not entirely sure that's a problem, but if it is then we have a clearly defined line before which instructions will be G_* and after which they'll be * (InstructionSelect) so we can add another callback (getFirstNonGenericPHI or something) and use it in the right places.

>> [*] 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.

Since some NEON stores handle up to 512 bits, once things are fully implemented we're likely to see things like this after legalization:

    %0(s512) = G_LOAD %ptr
    %1(s512) = (G_)?COPY %0

The optimum mapping for this is almost certainly %0(QQQQ), %1(Q,Q,Q,Q) and after InstructionSelection this would have to become something like

    %1.0 = COPY %0:qsub0
    %1.1 = COPY %0:qsub1
    %1.2 = COPY %0:qsub2
    %1.3 = COPY %0:qsub3.

Cheers.

Tim.


More information about the llvm-commits mailing list