Support for allowing direct VEXTRACT to 20-bit registers

[abhinay-anubola]

• This update introduces support for direct VEXTRACT to 20-bit registers by adding vextract.8/16/32 intrinsics as source nodes in the s20narrowing pass.
• The MachineVerifier has been updated to allow G_AIE_SEXT_EXTRACT_VECTOR_ELT and G_AIE_ZEXT_EXTRACT_VECTOR_ELT to accept 20-bit outputs.
• Additionally, tests have been added and updated to reflect these functional changes.

[krishnamtibrewala]

Given that you mentioned there are no QoR gain, I would recommend you to re look at the instruction that consume S20 type reg.
Because for the optimization starts to trace back from an instruction that consumes S20 type which might not be captured in isNativeS20Consumer function.

[andcarminati]

I suggest to not erase 2 instructions here, because we may corrupt the iterator. Let ExtMI to be removed by DCE.

[andcarminati]

Combiner engine may access freed memory:

    while (!WorkList.empty()) {
      MachineInstr *CurrInst = WorkList.pop_back_val();
      LLVM_DEBUG(dbgs() << "\nTry combining " << *CurrInst;);
      Changed |= tryCombineAll(*CurrInst);
      WLObserver->reportFullyCreatedInstrs();
    }

[andcarminati]

Question is, should we refactor void makeDeadMI(MachineInstr &MI, MachineRegisterInfo &MRI); as a common utility function?

[abhinay-anubola]

We cant erase just the TRUNC as it is input for EXT.

[andcarminati]

You will also erase MI (intrinsic) in the caller function.

[andcarminati]

I think we can trigger the same multiple erased instructions problem here.

[andcarminati]

We can have a description of the combiner here.

[andcarminati]

This looks like an assert. We always need constant signal to be able to handle this intrinsic.

[andcarminati]

I understood that this tryToCombineTruncExt is only safe because we know the range of the output of the defining instruction. However, it would be good to have this as a separated combiner (may looking to the input reg. def.). It will help to solve the erasing problem and we also can have different tests and, as a gift, less coupled code.

[konstantinschwarz]

Instead of doing this combine here, why don't we just use G_ASSERT_ZEXT/G_ASSERT_SEXT?
In your previous commit 16445fb,
we should pre-select

%0:_(s32) = G_INTRINSIC intrinsic(@llvm.aie2.vextract.elem8.I512), ...

into

%new:_(s32) = G_AIE_ZEXT_EXTRACT_VECTOR_ELT
%0:_(s32) = G_ASSERT_ZEXT %new, 16

Then you should get the G_TRUNC + G_ZEXT combine for free.

[andcarminati]

We should have something like:

    %0:_(s32) = G_CONSTANT i32 7
    %2:_(<32 x s16>) = COPY $x0
    %9:_(s20) = G_AIE_ZEXT_EXTRACT_VECTOR_ELT %2(<32 x s16>), %0(s32)
    %3:_(s20) = G_ASSERT_ZEXT %9, 16
    %4:_(s16) = G_TRUNC %3(s20)
    %5:_(s20) = G_ZEXT %4(s16)
    %6:_(p0) = G_CONSTANT i20 0
    %7:_(p0), %8:_(s20) = G_INTRINSIC intrinsic(@llvm.aie2.add.2d), %6(p0), %5(s20), %5(s20), %5(s20), %5(s20)
    PseudoRET implicit $lr, implicit %7(p0)

However, for SEXT case, there is no combine pattern AFAIK.

[andcarminati]

We can try to match this pattern explicitly looking to ASSERT, something like:

bool CombinerHelper::matchCombineSextTrunc(MachineInstr &MI, Register &Reg) {
  assert(MI.getOpcode() == TargetOpcode::G_SEXT && "Expected a G_SEXT");
  Register DstReg = MI.getOperand(0).getReg();
  Register SrcReg = MI.getOperand(1).getReg();
  LLT DstTy = MRI.getType(DstReg);
  if (mi_match(SrcReg, MRI,
               m_GTrunc(m_all_of(m_Reg(Reg), m_SpecificType(DstTy))))) {
    unsigned DstSize = DstTy.getScalarSizeInBits();
    unsigned SrcSize = MRI.getType(SrcReg).getScalarSizeInBits();
    MachineInstr* MIDef = MRI.getVRegDef(Reg);
    if (MIDef->getOpcode() != TargetOpcode::G_ASSERT_SEXT)
      return false;
    unsigned ExtBits = MIDef->getOperand(2).getImm();
    return SrcSize == ExtBits;
  }
  return false;
}

And apply replaceSingleDefInstWithReg

[konstantinschwarz]

Instead of hardcoding the G_ASSERT_SEXT, I'd suggest to use the KnownBits analysis to check if we have known sign bits: KB->computeNumSignBits(Reg)