[AIE2P] Improve `RegbankSelect` handling for load/store offset and post-increment addressing modes #337

abnikant · 2025-02-06T07:31:36Z

Improved register bank assignments (for accumulator and FIFO register banks) to support load/store post-increment, post-increment 2D, post-increment 3D, and offset addressing modes.

khallouh · 2025-02-06T10:06:51Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

+
+    // Prepare the three mapping indices.
+    std::vector<AIEBaseRegisterBankInfo::PartialMappingIdx> MappingIndices = {
+        getPartialMappingIdx(Ty), getAccPartialMappingIdx(Ty),


Can we just use getVecPartialMappingIdx here?

khallouh · 2025-02-06T10:15:54Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

+          OpdsMapping[Idx] = getValueMapping(OpRegBankIdx[Idx], OpSize[Idx]);
+        }
+      }
+      const InstructionMapping &VRegMapping = getInstructionMapping(


Nit: I find the name VRegMapping to be a bit confusing here since this is supposed to be an alternative mapping

khallouh · 2025-02-06T10:21:08Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

+  case AIE2P::G_AIE_POSTINC_3D_LOAD: {
+    const unsigned NumOperands = MI.getNumOperands();
+    const unsigned FirstSrcIdx = MI.getNumExplicitDefs();
+    unsigned MappingID = DefaultMappingID;


Any reason you start at DefaultMappingID instead of 1 for your alternative mapping IDs? DefaultMappingID is a UINT_MAX and you are incrementing it. It also mentions:

Identifier used when the related instruction mapping instance is generated by target independent code. Make sure not to use that identifier to avoid possible collision.

khallouh · 2025-02-06T10:23:15Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

+
+    // Prepare the three mapping indices.
+    std::vector<AIEBaseRegisterBankInfo::PartialMappingIdx> MappingIndices = {
+        getPartialMappingIdx(Ty), getAccPartialMappingIdx(Ty),


Same as for the loads, Can't we use getVecPartialMappingIdx instead of getPartialMappingIdx from the base which still relies on the element size?

khallouh · 2025-02-06T10:28:37Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

+    }
+
+    if ((VecRegOpIdx + 1) < NumOperands)
+      OpRegBankIdx[VecRegOpIdx + 1] = PMI_PTR;


Can we simply assert this (VecRegOpIdx + 1) < NumOperands instead and directly assign PMI_PTR? I think all of the store opcodes handled here should verify this condition.

yes, makes sense.

khallouh · 2025-02-06T10:30:10Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

+          OpdsMapping[Idx] = getValueMapping(OpRegBankIdx[Idx], OpSize[Idx]);
+        }
+      }
+      const InstructionMapping &VRegMapping = getInstructionMapping(


Same as for the loads. I would use a different name since this is not always a vector bank mapping

khallouh · 2025-02-06T10:34:31Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

@@ -705,7 +800,8 @@ bool AIE2PRegisterBankInfo::hasFifoInput(const MachineInstr &MI,
                                         const Register RegOp) const {
  auto *RI = static_cast<const AIEBaseRegisterInfo *>(
      MI.getParent()->getParent()->getSubtarget().getRegisterInfo());
-  switch (MI.getOpcode()) {
+  const unsigned Op = MI.getOpcode();
+  switch (Op) {


I had addressed a comment on my PR to directly use switch (MI.getOpcode()) since Op for 'opcode' can be confusing as we also have a RegOp argument for 'operand' this time. Could you keep it and do the same for usesAccReg or at least change the name to avoid confusion with RegOp?

khallouh · 2025-02-06T10:35:32Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

+  case TargetOpcode::G_STORE:
+  case AIE2P::G_AIE_OFFSET_STORE:
+  case AIE2P::G_AIE_POSTINC_STORE: {
+    const unsigned OpIdx = MI.getNumExplicitDefs();


How about 2D and 3D?

oh! missed updating the switch case, added now.

khallouh · 2025-02-06T10:35:56Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

+  case TargetOpcode::G_STORE:
+  case AIE2P::G_AIE_OFFSET_STORE:
+  case AIE2P::G_AIE_POSTINC_STORE: {
+    const unsigned OpIdx = MI.getNumExplicitDefs();


How about 2D and 3D?

khallouh · 2025-02-06T10:40:49Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

    MachineMemOperand *MMO = *MI.memoperands_begin();
    const unsigned MemSize = 8 * MMO->getSize().getValue();
    // Handle the example case as below
    /* %2:_(p0) = G_FRAME_INDEX %stack.0
       G_STORE %1(<32 x s32>), %2(p0)
       %4:_(<32 x s32>) = G_LOAD %2(p0) */
+    // Size of accumulator and fifo vectors on aie2p >= 512.
    if (MemSize >= 512) {


Could you remind me why the case above was handled according to the MemSize and why it should be greater than 512?
Edit: clarified

Ok, I just saw the comment, this based on the size of the acc/fifo on the target. In that case, can we just return earlier for anything smaller than 512?

khallouh · 2025-02-06T10:43:19Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

    }
+
+    // Update mapping flags based on the refined candidate.


I think if this just to address the case above, we can move it up inside the corresponding if case, or keep it here and remove it from above the if case. We don't have to ~~update~~ to do it twice.

khallouh · 2025-02-06T10:49:16Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

+// Given an instruction that produces a pointer used in a load operation,
+// return the candidate pointer register that should be traced
+// for determining the register bank mapping.
+const Register getUseCandidateReg(const MachineInstr &DefMI) {


Nit: getUseCandidatePointer

khallouh · 2025-02-06T10:58:28Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

+
+    // Assign PMI_PTR to the next operand if within bounds
+    if ((VecRegOpIdx + 1) < NumOperands)
+      OpRegBankIdx[VecRegOpIdx + 1] = PMI_PTR;


Same as above, can we simply assert here instead of the if?

khallouh · 2025-02-10T08:00:56Z

llvm/test/CodeGen/AIE/aie2p/GlobalIsel/regbankselect-fifo-insn.mir

+    ; FAST-NEXT: $lfl0 = COPY [[AIE_OFFSET_LOAD]](<8 x s64>)
+    %1:_(p0) = COPY $p0
+    %2:_(s20) = G_CONSTANT i20 448
+    %0:_(<8 x s64>) = G_AIE_OFFSET_LOAD %1:_(p0), %2:_(s20) :: (load (<8 x s64>))


Could you add a test for G_AIE_OFFSET_STORE?

added tests.

khallouh · 2025-02-10T08:13:05Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

-      UseCandidate = DefMI->getOperand(0).getReg();
+    Register PtrReg = MI.getOperand(FirstSrcIdx).getReg();
+    MachineInstr *DefMI = MRI.getVRegDef(PtrReg);
+    if (DefMI) {


Isn't that guaranteed by SSA?

~~Which seems to make the following block above kind of dead code~~ as we would update the use candidate every time

if (isUseAccInsn(MRI, TRI, UseCandidate)) isAccRegMapping = true; if (isUseFifoInsn(MRI, TRI, UseCandidate)) isFifoPhysRegMapping = true;

Ah ok so we would update the use candidate every time but we still need the first block for when the the load feeds acc/fifo instructions directly and not through the pointer.

khallouh · 2025-02-10T10:08:07Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

+    // for MemSize < 512, fallback to base instruction mapping.
+    if (MemSize < 512)
+      return AIEBaseRegisterBankInfo::getInstrMapping(MI);
+
    // Handle the example case as below
    /* %2:_(p0) = G_FRAME_INDEX %stack.0
       G_STORE %1(<32 x s32>), %2(p0)
       %4:_(<32 x s32>) = G_LOAD %2(p0) */


I'm not sure if we need to handle this case and update the use candidate. Here is the code after instruction-select for test_v16x32_spill_reload without this change:

bb.0.entry: %0:fifo512 = COPY $lfl1 VST_dmx_sts_fifohl_spill %0, %stack.0, implicit $sp :: (store (<16 x s32>)) %3:vec512 = VLDA_dmx_lda_x_spill %stack.0, implicit $sp :: (dereferenceable load (<16 x s32>)) VST_dmx_sts_x_spill %3, %stack.1, implicit $sp :: (volatile store (<16 x s32>)) %4:fifo512 = VLDA_dmx_lda_fifohl_spill %stack.1, implicit $sp :: (volatile dereferenceable load (<16 x s32>)) $lfl0 = COPY %4 PseudoRET implicit $lr, implicit $lfl0

We simply use a vector load and store instead of fifo load and store, no cross bank copies are introduced.

Indeed. I have removed this special case. I don't find a case where it will help in better register bank assignment. We can always add if there is a need.

As I understands we are handling this

%1:_(<16 x s32>) = COPY $lfl1 %2:_(p0) = G_FRAME_INDEX %stack.0 G_STORE %1(<16 x s32>), %2(p0) :: (store (<16 x s32>)) %4:_(<16 x s32>) = G_LOAD %2(p0) :: (dereferenceable load (<16 x s32>)) .. .. uses %4

Only issue I can see is, if we want to select uses %4 instruction based on %4 we might hit vector variant of instruction always and need cross bank copy always if there are other variants we can select.

Also, if you would like to remove this special case you can remove AIE2PRegisterBankInfo::hasFifoInput and corresponding accumulator function. It seems dead code.

case TargetOpcode::G_STORE: case AIE2P::G_AIE_OFFSET_STORE: case AIE2P::G_AIE_POSTINC_STORE: case AIE2P::G_AIE_POSTINC_2D_STORE: case AIE2P::G_AIE_POSTINC_3D_STORE: { const unsigned OpIdx = MI.getNumExplicitDefs(); auto *RB = getRegBank(MI.getOperand(OpIdx).getReg(), MRI, TRI); if (RB == &AIE2P::FifoRegBank) return true; break; }

Here is an example usecase

; FAST-LABEL: name: test_v16acc32_spill_reload ; FAST: [[COPY:%[0-9]+]]:accregbank(<16 x s32>) = COPY $bmll1 ; FAST-NEXT: [[COPY1:%[0-9]+]]:gprregbank(s32) = COPY $r0 ; FAST-NEXT: [[FRAME_INDEX:%[0-9]+]]:ptrregbank(p0) = G_FRAME_INDEX %stack.0 ; FAST-NEXT: G_STORE [[COPY]](<16 x s32>), [[FRAME_INDEX]](p0) :: (store (<16 x s32>)) ; FAST-NEXT: [[LOAD:%[0-9]+]]:vregbank(<16 x s32>) = G_LOAD [[FRAME_INDEX]](p0) :: (dereferenceable load (<16 x s32>)) ; FAST-NEXT: [[ADD:%[0-9]+]]:vregbank(<16 x s32>) = G_ADD [[LOAD]], [[LOAD]] ; FAST-NEXT: [[COPY2:%[0-9]+]]:accregbank(<16 x s32>) = COPY [[ADD]](<16 x s32>) ; FAST-NEXT: G_INTRINSIC_W_SIDE_EFFECTS intrinsic(@llvm.aie2p.mcd.write.acc32), [[COPY2]](<16 x s32>), [[COPY1]](s32) ; FAST-NEXT: PseudoRET implicit $lr %1:_(<16 x s32>) = COPY $bmll1 %3:gprregbank(s32) = COPY $r0 %2:_(p0) = G_FRAME_INDEX %stack.0 G_STORE %1(<16 x s32>), %2(p0) :: (store (<16 x s32>)) %4:_(<16 x s32>) = G_LOAD %2(p0) :: (dereferenceable load (<16 x s32>)) %5:_(<16 x s32>) = G_ADD %4, %4 G_INTRINSIC_W_SIDE_EFFECTS intrinsic(@llvm.aie2p.mcd.write.acc32), %5(<16 x s32>), %3(s32) PseudoRET implicit $lr

Here is an example usecase

; FAST-LABEL: name: test_v16acc32_spill_reload ; FAST: [[COPY:%[0-9]+]]:accregbank(<16 x s32>) = COPY $bmll1 ; FAST-NEXT: [[COPY1:%[0-9]+]]:gprregbank(s32) = COPY $r0 ; FAST-NEXT: [[FRAME_INDEX:%[0-9]+]]:ptrregbank(p0) = G_FRAME_INDEX %stack.0 ; FAST-NEXT: G_STORE [[COPY]](<16 x s32>), [[FRAME_INDEX]](p0) :: (store (<16 x s32>)) ; FAST-NEXT: [[LOAD:%[0-9]+]]:vregbank(<16 x s32>) = G_LOAD [[FRAME_INDEX]](p0) :: (dereferenceable load (<16 x s32>)) ; FAST-NEXT: [[ADD:%[0-9]+]]:vregbank(<16 x s32>) = G_ADD [[LOAD]], [[LOAD]] ; FAST-NEXT: [[COPY2:%[0-9]+]]:accregbank(<16 x s32>) = COPY [[ADD]](<16 x s32>) ; FAST-NEXT: G_INTRINSIC_W_SIDE_EFFECTS intrinsic(@llvm.aie2p.mcd.write.acc32), [[COPY2]](<16 x s32>), [[COPY1]](s32) ; FAST-NEXT: PseudoRET implicit $lr %1:_(<16 x s32>) = COPY $bmll1 %3:gprregbank(s32) = COPY $r0 %2:_(p0) = G_FRAME_INDEX %stack.0 G_STORE %1(<16 x s32>), %2(p0) :: (store (<16 x s32>)) %4:_(<16 x s32>) = G_LOAD %2(p0) :: (dereferenceable load (<16 x s32>)) %5:_(<16 x s32>) = G_ADD %4, %4 G_INTRINSIC_W_SIDE_EFFECTS intrinsic(@llvm.aie2p.mcd.write.acc32), %5(<16 x s32>), %3(s32) PseudoRET implicit $lr

yes, we have some cases in mllib too, I noticed that while running mllib. I will bring back this code. I am already working on to refine this.

It would be great if you could also include a reduced test case from mllib @abnikant

I couldn't reproduce with the mllib tests I tried. I think we can drop it now and take it later if there is a need?

khallouh · 2025-02-10T10:32:55Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

@@ -251,32 +251,125 @@ AIE2PRegisterBankInfo::getInstrAlternativeMappings(
  const MachineRegisterInfo &MRI = MF.getRegInfo();
  switch (MI.getOpcode()) {
  case TargetOpcode::G_LOAD:
-  case TargetOpcode::G_STORE: {
+  case AIE2P::G_AIE_OFFSET_LOAD:
+  case AIE2P::G_AIE_POSTINC_LOAD:


How about G_AIE_OFFSET_ZEXTLOAD and G_AIE_OFFSET_SEXTLOAD?

khallouh · 2025-02-10T10:33:52Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

-  case TargetOpcode::G_LOAD: {
+  case TargetOpcode::G_LOAD:
+  case AIE2P::G_AIE_OFFSET_LOAD:
+  case AIE2P::G_AIE_POSTINC_LOAD:


How about G_AIE_OFFSET_ZEXTLOAD and G_AIE_OFFSET_SEXTLOAD?

We are falling back to Base Implementation for Size < 512.

andcarminati · 2025-02-10T10:40:19Z

llvm/lib/Target/AIE/AIE2InstrInfo.cpp

@@ -229,6 +229,13 @@ unsigned AIE2InstrInfo::getOffsetMemOpcode(unsigned BaseMemOpcode) const {
  llvm_unreachable("not a generic load/store");
 }

+bool AIE2InstrInfo::isGenericOffsetMemOpcode(unsigned Opcode) const {


I would say that all G_AIE* are target specific. I feel that Generic (besides of G) can be a bit confusing

As mentioned in other PR, we need to update other hooks as well to remove 'Generic'. Possibly we can do it in other/separate PR?

khallouh

Since you add the regbankselect support for AIE's load and store opcodes in general. It would be nice to test the other assignments not just fifo512 and acc512.
For scalars offset and postinc, there is these 2 tests for AIE2 which you can extend for AIE2P
regbankselect-offset-postinc-store.mir and regbankselect-offset-postinc-load.mir. I couldn't find any for vectors or 2D/3D

khallouh · 2025-02-10T10:45:55Z

Note: all my review comments are concerning the 2nd commit regarding RegBankSelect. For the 1st commit (enabling combines), there is another PR #323

khallouh · 2025-02-10T10:48:16Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

+    // Select the operand index for VecReg.
+    const unsigned VecRegOpIdx = MI.getNumExplicitDefs();
+    Register VecReg = MI.getOperand(VecRegOpIdx).getReg();
+    if (!VecReg)
      break;


Why not return the base implementation?

Also, can we return earlier for any type smaller than 512 like we do for the loads? since we are trying to assign either the accumulator or fifo bank.

yes, now we return early for Size < 512.

abnikant · 2025-02-11T11:30:42Z

Since you add the regbankselect support for AIE's load and store opcodes in general. It would be nice to test the other assignments not just fifo512 and acc512. For scalars offset and postinc, there is these 2 tests for AIE2 which you can extend for AIE2P regbankselect-offset-postinc-store.mir and regbankselect-offset-postinc-load.mir. I couldn't find any for vectors or 2D/3D

enabled these for aie2p and also added tests for vector. 2D/3D tests were already added for accumulator and fifo registers.

niwinanto · 2025-02-11T20:43:14Z

llvm/test/CodeGen/AIE/aie2p/GlobalIsel/regbankselect-accumulator-insn.mir

@@ -205,7 +205,7 @@ body:             |
    ; FAST-NEXT: [[FRAME_INDEX:%[0-9]+]]:ptrregbank(p0) = G_FRAME_INDEX %stack.0
    ; FAST-NEXT: [[FRAME_INDEX1:%[0-9]+]]:ptrregbank(p0) = G_FRAME_INDEX %stack.1
    ; FAST-NEXT: G_STORE [[COPY]](<16 x s32>), [[FRAME_INDEX]](p0) :: (store (<16 x s32>))
-    ; FAST-NEXT: [[LOAD:%[0-9]+]]:accregbank(<16 x s32>) = G_LOAD [[FRAME_INDEX]](p0) :: (dereferenceable load (<16 x s32>))
+    ; FAST-NEXT: [[LOAD:%[0-9]+]]:vregbank(<16 x s32>) = G_LOAD [[FRAME_INDEX]](p0) :: (dereferenceable load (<16 x s32>))


Are we regressing here?

See my comment #337 (comment)

khallouh · 2025-02-12T09:59:50Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

-    // Base Alternative Mapping for size <= 256.
-    if (Size <= 256)
-      break;
+    const unsigned Size = getSizeInBits(DstReg, MRI, TRI);


Nit: DstSize

nit: DstRegTy

khallouh · 2025-02-12T10:00:29Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

-    AltMappings.push_back(&AccRegMapping);
+    Register VecReg = MI.getOperand(VecRegOpIdx).getReg();
+    const LLT Ty = MRI.getType(VecReg);
+    const unsigned Size = getSizeInBits(VecReg, MRI, TRI);


Nit: VecRegTy and VecRegSize

khallouh · 2025-02-12T10:01:30Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

+    // If the register already belongs to a known bank, just return.
+    if (getRegBank(UseCandidate, MRI, TRI) == &AIE2P::AccRegBank ||
+        getRegBank(UseCandidate, MRI, TRI) == &AIE2P::FifoRegBank)
+      return AIEBaseRegisterBankInfo::getInstrMapping(MI);


Should we also return if we know it is in the vector bank?

khallouh · 2025-02-12T10:02:59Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

+    Register VecReg = MI.getOperand(VecRegOpIdx).getReg();
+    // Size of accumulator and fifo vectors on aie2p >= 512.
+    // for VecSize < 512, fallback to base instruction mapping.
+    if (!VecReg || MRI.getType(VecReg).getSizeInBits() < 512)


Why do you need to check if(!VecReg)?

not needed. dropped.

khallouh · 2025-02-12T10:07:59Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

+    auto *DefRegBank = getRegBank(VecReg, MRI, TRI);
+    // Only process if VecReg is defined in Accumulator or Fifo register banks.
+    if (DefRegBank != &AIE2P::AccRegBank && DefRegBank != &AIE2P::FifoRegBank)
+      return AIEBaseRegisterBankInfo::getInstrMapping(MI);


Why not process the vector bank ones as well?

we do the analysis to assign acc and fifo regbanks.

niwinanto · 2025-02-12T15:03:10Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

@@ -255,32 +255,125 @@ AIE2PRegisterBankInfo::getInstrAlternativeMappings(
  const MachineRegisterInfo &MRI = MF.getRegInfo();
  switch (MI.getOpcode()) {
  case TargetOpcode::G_LOAD:
-  case TargetOpcode::G_STORE: {
+  case AIE2P::G_AIE_OFFSET_LOAD:


Do we really care about the alternative mapping? Since the cost is same, I think we always stick to the instruction mapping. May be you can check with --check-prefix=COMMON,GREEDY in the test. I believe both fast and greedy produces the same result.

yes, we do need in many cases, and also cost might change later.

Could you update the tests removing --check-prefix=GREEDY and --check-prefix=GREEDY , I do not see any tests using alternative mappings.

niwinanto · 2025-02-12T15:21:31Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

+  case AIE2P::G_AIE_POSTINC_2D_STORE:
+  case AIE2P::G_AIE_POSTINC_3D_STORE: {
+    const unsigned OpIdx = MI.getNumExplicitDefs();
+    auto *RB = getRegBank(MI.getOperand(OpIdx).getReg(), MRI, TRI);


I am not sure OpIdx is the right value. As I understand, we would like to check whether the vector to be store is a FifoReg. Now we look for the pointer and it will always return false.

why it is a pointer operand ?

This Idx should point to the first source operand.

Yes, you are right. I got confused between LOAD.

andcarminati · 2025-02-12T17:51:43Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

+    // For 2048-bit sizes, mapping is restricted to the accumulator bank.
+    // Also, if the instruction has any implicit defs/uses, leave it alone.
+    if (Size <= 256 || Size == 2048 ||
+        MI.getNumOperands() != MI.getNumExplicitOperands())


Is there any valid case of MI.getNumOperands() != MI.getNumExplicitOperands() considering loads?

not, needed. I dropped this check.

andcarminati · 2025-02-12T18:00:10Z

llvm/lib/Target/AIE/aie2p/AIE2PRegisterBankInfo.cpp

+    }
+
+    // Assign PMI_PTR to the next operand if within bounds
+    assert(((VecRegOpIdx + 1) < NumOperands) && "RegOpIdx + 1 out of bound");


nit: VecRegOpIdx + 1 out of bounds

…st-increment addressing modes

abnikant · 2025-02-14T16:04:56Z

Also, I ran mllib 3 days back, there was no extra failure. I have fired the run again, will post the result once done.

abnikant requested review from abhinay-anubola, andcarminati, F-Stuckmann, gbossu, katerynamuts, khallouh, konstantinschwarz, martien-de-jong, niwinanto, SagarMaheshwari99 and stephenneuendorffer as code owners February 6, 2025 07:31

abnikant force-pushed the aie2p.postinc.offset.ld.st.regbank branch 2 times, most recently from 123a229 to 57ae156 Compare February 6, 2025 08:37

khallouh reviewed Feb 6, 2025

View reviewed changes

abnikant force-pushed the aie2p.postinc.offset.ld.st.regbank branch 4 times, most recently from 635c08d to 614a302 Compare February 6, 2025 11:53

abnikant force-pushed the aie2p.postinc.offset.ld.st.regbank branch 2 times, most recently from 09958b9 to 54ead3e Compare February 10, 2025 06:25

khallouh reviewed Feb 10, 2025

View reviewed changes

andcarminati reviewed Feb 10, 2025

View reviewed changes

khallouh reviewed Feb 10, 2025

View reviewed changes

abnikant force-pushed the aie2p.postinc.offset.ld.st.regbank branch from 54ead3e to e9dcf85 Compare February 11, 2025 11:24

abnikant force-pushed the aie2p.postinc.offset.ld.st.regbank branch from e9dcf85 to f75e1d3 Compare February 11, 2025 17:33

niwinanto reviewed Feb 11, 2025

View reviewed changes

khallouh reviewed Feb 12, 2025

View reviewed changes

niwinanto reviewed Feb 12, 2025

View reviewed changes

andcarminati reviewed Feb 12, 2025

View reviewed changes

[AIE2P] Improve RegbankSelect handling for load/store offset and po…

6e26d97

…st-increment addressing modes

abnikant force-pushed the aie2p.postinc.offset.ld.st.regbank branch from f75e1d3 to 6e26d97 Compare February 14, 2025 15:50

[AIE2P] Improve RegbankSelect handling for load/store offset and post-increment addressing modes #337

Are you sure you want to change the base?

[AIE2P] Improve RegbankSelect handling for load/store offset and post-increment addressing modes #337

Conversation

abnikant commented Feb 6, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

khallouh Feb 6, 2025 • edited Loading

Choose a reason for hiding this comment

khallouh Feb 6, 2025 • edited Loading

Choose a reason for hiding this comment

khallouh Feb 6, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

khallouh Feb 10, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

khallouh left a comment

Choose a reason for hiding this comment

khallouh commented Feb 10, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

abnikant commented Feb 11, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

niwinanto Feb 12, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

niwinanto Feb 14, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

abnikant commented Feb 14, 2025

[AIE2P] Improve `RegbankSelect` handling for load/store offset and post-increment addressing modes #337

[AIE2P] Improve `RegbankSelect` handling for load/store offset and post-increment addressing modes #337

khallouh Feb 6, 2025 •

edited

Loading

khallouh Feb 6, 2025 •

edited

Loading

khallouh Feb 6, 2025 •

edited

Loading

khallouh Feb 10, 2025 •

edited

Loading

khallouh commented Feb 10, 2025 •

edited

Loading

niwinanto Feb 12, 2025 •

edited

Loading

niwinanto Feb 14, 2025 •

edited

Loading