AllocateSharedMemoryPass has possibility to allocate SLM size greater than device max share memory

[LiyangLingIntel]

Running gemm kernels like gemm_splitk_benchmark.py with the latest llvm-target branch will fail for

triton.runtime.errors.OutOfResources: out of resource: shared memory, Required: 266240, Hardware limit: 131072.

[chengjunlu]

Information from @whitneywhtsang

FYI: The failures reported in CI are due to enabling large 2d block load a74da7d.

[LiyangLingIntel]

This task is still under progress.
This issue maybe partially cased by that we use larger size of dpas layout with repCluster while the allocation analysis algorithm uses NvidiaMmaLayout, the calculated buffer scratch size would be different.
On the other hand, the original allocation algorithm does not seem to be quite perfect, it potentially allocates oversized shared memory. It needs more investigation to find an appropriate solution.

[LiyangLingIntel]

The root cause of this issue is the large 2d load with large repCluster requires large size of shared local memory for ConvertLayout op when converting dpas layout to blocked layout. Minor changes to the allocation pass does not help.
After syncing with @chengjunlu, we think

• One possible solution is to remove the ConvertLayout op for the stream-k and split-k by propagating dpas layout to atomic op.
• The another one is to reduce the repCluster size when we find there is a ConvertLayout op cannot be removed.
  We can use this way as a short term solution to work around this issue. For the long term, there would not be this issue when leveraging the linear layout.

I'm trying to do some changes on the first way, if there are some common ops make the ConvertLayout op not removable. I'll switch to the second way which is add another pass to check and reduce large 2d load size to make it work functionally at first.