[Codegen] Add phase group information into a new enum for shared mem info

[Muzammiluddin-Syed-ECE]

This is the first of two PRs meant to improve the xor shuffling strategy for resolving bank conflicts. See: #24428

This change does two things:

1. Adds phase group information for CDNA4 arch, allowing us to more rigorously simulate bank conflicts.
2. Introduces a new enum "SharedMemoryModel" behind which we move all shared memory related information such as number of banks and phase group info.

[kuhar]

Why is the shared mem model so coarse-grained? For example, the number of banks changed between cdna3 and cdna4.

[Yu-Zhewen]

I was reading the original PR comment: #24428 (comment). Just wondering, would it be a better choice to keep bank_count, bank_width, and phase_schedule as orthogonal fields? Bundling them into one enum would mean adding a new SharedMemoryModel case for every change, which might feel like a bit ofburden

[Muzammiluddin-Syed-ECE]

Why is the shared mem model so coarse-grained? For example, the number of banks changed between cdna3 and cdna4.

The coarseness reflects how little the shared mem model changes in the features it tracks across architectures.

// CDNA1-3: 32 banks, contiguous phase scheduling.
def IREEGPU_SharedMemModelCDNA
    : I32EnumAttrCase<"CDNA", 1, "cdna">;
// CDNA4 (gfx950): 64 banks, non-contiguous 4-phase scheduling for
// ds_read_b128. Phase table determined by empirical measurement.
def IREEGPU_SharedMemModelCDNA4
    : I32EnumAttrCase<"CDNA4", 2, "cdna4">;

For your example, there is only a real distinction in the cdna line between cdna1-3 and cdna4 so only cdna4 is given its own enum.

edit: Thinking on it longer, we don't lose anything by having an entry per arch and gain clarity. ill just make it more fine-grained.

[Muzammiluddin-Syed-ECE]

I was reading the original PR comment: #24428 (comment). Just wondering, would it be a better choice to keep bank_count, bank_width, and phase_schedule as orthogonal fields? Bundling them into one enum would mean adding a new SharedMemoryModel case for every change, which might feel like a bit ofburden

Because these fields represent hardware details, they are extremely stable and shouldn't change beyond adding new entries for every new piece of hardware.

[kuhar]

Can you rename it to indicate these are read phase groups? Writes have their own groups.

[Muzammiluddin-Syed-ECE]

I'd rather add a todo to add an access type function argument like AccessType rw where AccessType is an enum with values {READ, WRITE}.

getPhaseGroups(SharedMemoryModel model, int64_t readBytes, int64_t numThreads, AccessType rw)