Updated the op documentation and addressed the comments.

Hi @ftynse @nicolasvasilache. Could you kindly review my submitted patch? Thanks!

In D144666#4214523, @hw-yuexy wrote:

Hi Amir,

I have a question regarding the promote op patch.

When I chain 2 promote op together, both trying to promote operands in a tiled linalg.matmul, with the first one copies from global memory to L1, the second one copies from L1 to L0. I found all memref.copy op are placed in the inner most loop with copy sizes dependent on the inner most loop IV. However, this can lead to bad performance because when moving from GM to L1, it's often more profitable to move larger chunks of data (i.e. we can hoist the GM->L1 memref.copy ops into an outer loop, copying more data). I'm wondering if there are plans to make promote op more flexible, so that it can hoist some memref.copy ops to outer loops when possible?

Thanks.

Fix missing import after applying patch

rebased

Thank you! I don't have the commit access to LLVM project for applying this patch.

Hi @nicolasvasilache, just wanted to check in and see if you had a chance to review the promotion logic yet. If you have any thoughts or feedback, it would be great to hear them. Thanks!

Fixed anti-pattern and return condition of allocateSubviewGPUMemoryInAddressSpace function

Update the diff based on the comment

Fix merge conflict

Thank you! I don't have the commit access to LLVM project for applying this patch.

Add /// comments. Replaced expensive query attribute with a simple code. Change the description of GPUMemorySpaceMappingAttr to reflect OpenCL terminology. Also, uploaded the patch with -U99999 flag

Added a new device mapping enum for GPU memory hierarchy, removed comments, refactor allocation, deallocation, and copy function to linalg/Transform/promotion.cpp

Format the file and fix wrong diff file not including the private memory copy