Inconsistent DMA benefit between --iree-rocm-target=gfx950 and --iree-rocm-target=mi355x

### BOO Test case ``` aten::addmm "[[2048], [150000, 1024], [1024, 2048], [], []]" "['c10::BFloat16', 'c10::BFloat16', 'c10::BFloat16', 'Scalar', 'Scalar']" "[[1], [1024, 1], [1, 1024], [], []]" "['', '', '', '1', '1']" ``` ### Observed times | Config | Time (us) | |--------|-----------| | mi355x DMA ON | **1881.2** | | mi355x DMA OFF | 1003.8 | | gfx950 DMA ON | 837.2 | | gfx950 DMA OFF | 870.0 | - all tests run on OSSCI MI355x, with two different target flags: `--iree-rocm-target=mi355x` and `--iree-rocm-target=gfx950` - gfx950 DMA ON improves over DMA OFF (+3.8%), while mi355x DMA ON regresses severely (-87.4%). - mi355x is slower than gfx950 regardless of DMA ON or OFF ### Analysis The problem size (M=150000, K=1024, N=2048) is classified as `LargeGemm` on gfx950 but `MediumGemm` on mi355x, same underlying issue as https://github.com/iree-org/iree/issues/23902. This classification difference already causes mi355x DMA OFF (1003.8 us) to be slower than gfx950 DMA OFF (870.0 us). DMA multi-buffering compounds the problem. With `prefetchNumStages=2`, operand LDS is doubled to **96KB**, exceeding half of available 160KB LDS and limiting occupancy to **1 WG/CU**. At 1 WG/CU there is no latency hiding. | Config | LDS | WGs/CU | |--------|-----|--------| | mi355x DMA ON | **96KB** | **1** | | mi355x DMA OFF | 49KB | 2 | | gfx950 DMA ON | 32KB | 4 | | gfx950 DMA OFF | 17KB | 3 | One approach is to reject DMA when it would reduce LDS-limited occupancy below 2 WGs/CU (i.e., ensure DMA LDS stays within half the available LDS, ~80KB on CDNA4). However, this rejection may be too aggressive, it would effectively reject DMA for **all** `MediumGemm` shapes. The deeper question is whether maintaining `WGs/CU >= 2` is always worth giving up DMA. The need for latency hiding here is a symptom of a suboptimal tile size choice, regardless of whether DMA is ON or OFF in this example. If the underlying `MediumGemm` misclassification is fixed and we don't need the latency hiding provided by `WGs/CU >= 2` anyway.