[AIEX] Hazard Recognizer drops Load Store MemoryBank conflicts by F-Stuckmann · Pull Request #981 · Xilinx/llvm-aie

F-Stuckmann · 2026-05-04T11:38:57Z

I have a conflict() refactor in here. We previously had multiple different conflict locations and i unified them in this PR.

andcarminati · 2026-05-04T13:35:55Z

Could we verify if two stores may collide if they are one cycle apart? For example, we have stores accessing memory on cycle 5, 6 or even 7. If a 5-cycle store is scheduled just before a 6-cycle store, they will stall the memory interface. Could we still handle store banks separately?

F-Stuckmann · 2026-05-04T13:50:49Z

I think we already handle this because already use the same resources.
Nonetheless i will add a unit-test to verify

martien-de-jong · 2026-05-06T13:12:50Z

-      };
+      },
+      FUDepthLimit);
+  return Found;


why not return anyStage(...) ?

I deleted the NFC refactor commit, it was just adding noise

martien-de-jong · 2026-05-11T15:31:56Z

+
+  // Same cycle without slot, resources don't overlap -> no hazard.
+  EXPECT_FALSE(HR.hazard(14, 0, /*SlotSet=*/0b0, /*MemoryBanks=*/0,
+                         /*ObjectsBits=*/0, /*MemoryAccessCycle=*/{6}));


As discussed also expect no hazard at -2.

Stop tracking memory-bank usage for store instructions in the AIE scoreboard. Two facts justify this: 1. Loads and stores use separate HW ports, so a load and a store on the same bank in the same cycle never conflict. 2. AIE2/AIE2P/AIE2PS each have a single store slot

Two unit tests document the post-load-only-bank-tracking behaviour for stores, in response to a review question: now that stores no longer populate the memory-bank scoreboard, what keeps two stores from issuing in the same cycle? * storeStoreSameMemoryCycleSerializesViaSlot -- two stores with the same MemoryAccessCycles and an overlapping st_slot collide at the emission cycle via the slot scoreboard, while one-cycle-apart deltas are clear (no spurious bank conflict). * storeStoreDifferentMemoryCycleSerializesViaSlot -- two stores with *different* MemoryAccessCycles (e.g. {5} vs {6}/{7}) at the same emission cycle still collide via the slot scoreboard, regardless of memory-cycle disagreement. Also verifies that a staggered emission whose memory accesses would have aligned under the previous all-stores bank-tracking policy reports no hazard, since stores now carry zero bank bits. Both tests pass MemoryBanks=0 to model the new policy and rely on the overlapping SlotSet to drive the hazard, mirroring the bankConflictHazard tests' use of MockStages classes 1 and 3 (no resource overlap).

F-Stuckmann requested review from SagarMaheshwari99, abhinay-anubola, abnikant, andcarminati, katerynamuts, khallouh, konstantinschwarz, martien-de-jong, mludevid, niwinanto and stephenneuendorffer as code owners May 4, 2026 11:38