[AIE2P] Fix Accumulator Register Bank assignment for G_STORE

[khallouh]

For G_STORE, we look at the bank of the register in the defining instruction but we assume that this will be at index zero, which has been the case for AIE2P's intrinsics defining accumulators but not true in general.

[andcarminati]

LGTM.

[niwinanto]

Since you are at it , could you fix this typo.
// G_STORE %4(s32), %2(p0) :: (store (s32))

[niwinanto]

Now I am bit more confused. if vreg is already accregbank, why we need the special handling. return AIEBaseRegisterBankInfo::getInstrMapping(MI); itself enough right?

Before this change, at least we are looking at a different register than vreg for come cases, but I dont know the usecase.

[niwinanto]

@khallouh You missed this comment.

[khallouh]

I think we were looking at VReg before the change but we were assuming it would always be at index 0. Do you have an example where they are different or any case that I missed?

[niwinanto]

The comment above the changed line

    // %3:_(<16 x s64>), %4:_(s32) = llvm.aie2p.scd.expand.ACC1024.incr),
    //G_STORE %4(s32), %2(p0) :: (store (s32))

Before change we check for %3:_(<16 x s64>) is DefRegBank and now %4(s32).

Also, as I mentioned above, if %4(s32) is the indented register, AIEBaseRegisterBankInfo::getInstrMapping(MI); might be enough.

[khallouh]

%4(s32) is not the intended register and AIEBaseRegisterBankInfo::getInstrMapping(MI); is already called for that case.
That comment is now outdated. Most probably that type check (Type.getSizeInBits() > 256) was just a hack around the above case. @abnikant can you confirm?

    // Add an additional typesize check to avoid matching the following case.
    // %3:_(<16 x s64>), %4:_(s32) = llvm.aie2p.scd.expand.ACC1024.incr),
    // %1(s32) G_STORE %4(s32), %2(p0) :: (store (s32))
    if (RB == &AIE2P::AccRegBank && Type.getSizeInBits() > 256) {
      OpRegBankIdx[0] = getAccPartialMappingIdx(MRI.getType(VReg));
      OpRegBankIdx[1] = PMI_PTR;
      return AIEBaseRegisterBankInfo::getInstrMappingFinal(MI, Cost, OpSize,
                                                           OpRegBankIdx);
    }
    return AIEBaseRegisterBankInfo::getInstrMapping(MI);

We don't need the type check anymore now that the bug is fixed. That example precisely shows what this fixes where if it weren't for that check (Type.getSizeInBits() > 256) we would be assigning the accumulator bank to a store of a scalar. Now we are looking at the correct %4(s32) and it won't have the accumulator bank assigned which means we will return AIEBaseRegisterBankInfo::getInstrMapping(MI); exactly as we expect.

I opened #285 to remove the redundant type check and the outdated comment.

[abnikant]

yes, true.

[niwinanto]

@abnikant Why we dont use isUseAccInsn for G_STORE case?