[Proton][Dialect] Middle-end Proton operator definitions #5754
Conversation
| } | ||
|
|
||
| def PT_FinalizeOp : PT_Op<"finalize", [ | ||
| MemoryEffects<[MemRead<SharedMemory>]>, |
There was a problem hiding this comment.
It's a bit confused to me why FinalizeOp has explicit resources but CircularRecordOp has the default resources.
TTG_MemDescType can refer to two different memory, either the old shared memory or the new tensor memory on Blackwell. I think this part has to be better clarified.
BTW, I agree it's also not clear in TritonOps.td. So maybe you can just go use GlobalMemory and SharedMemory considering that we only target GPUs for now.
There was a problem hiding this comment.
It's a bit confused to me why FinalizeOp has explicit resources but CircularRecordOp has the default resources.
The rationale behind it is that "DefaultResource" is everything. FinalizeOp touches shared memory with read and global memory with read + write. Then, if another OP has shared memory read, you are good to re-order them but you can't reorder an OP that reads global memory (let's say the address is symbolic). For RecordOp , we are not supposed to move around it because it is for profiling. So I give it DefaultResource. For InitOp and FinalizeOp, compiler can do whatever it wants as long as it obeys SharedMemory/GlobalMemory side effects.
TTG_MemDescType can refer to two different memory, either the old shared memory or the new tensor memory on Blackwell. I think this part has to be better clarified.
I could explicitly describe that in the OP def's comment and has the OP verifier to check the mem_desc's address space, making sure it is shared mem. What do you think?
There was a problem hiding this comment.
Maybe let's keep it as what it is and change it later
| } | ||
|
|
||
| def PT_FinalizeOp : PT_Op<"finalize", [ | ||
| MemoryEffects<[MemRead<SharedMemory>]>, |
There was a problem hiding this comment.
Maybe let's keep it as what it is and change it later
…#5754) This PR is a follow-up of triton-lang#5677 for proton compiler mid-end support, focusing on op definition. Specifically, we 1. added the tablegen definitions of the proton mid-end operators, 2. removed attributes of the front-end `RecordOp` (make it a true marker), 3. cleaned up the dialect's macro. --------- Co-authored-by: Yuanwei Fang <[email protected]>
This PR is a follow-up of #5677 for proton compiler mid-end support, focusing on op definition. Specifically, we 1. added the tablegen definitions of the proton mid-end operators, 2. removed attributes of the front-end `RecordOp` (make it a true marker), 3. cleaned up the dialect's macro. --------- Co-authored-by: Yuanwei Fang <[email protected]>
This PR is a follow-up of #5677 for proton compiler mid-end support, focusing on op definition. Specifically, we 1. added the tablegen definitions of the proton mid-end operators, 2. removed attributes of the front-end `RecordOp` (make it a true marker), 3. cleaned up the dialect's macro. --------- Co-authored-by: Yuanwei Fang <[email protected]>
This PR is a follow-up of #5677 for proton compiler mid-end support, focusing on op definition. Specifically, we 1. added the tablegen definitions of the proton mid-end operators, 2. removed attributes of the front-end `RecordOp` (make it a true marker), 3. cleaned up the dialect's macro. --------- Co-authored-by: Yuanwei Fang <[email protected]>
This PR is a follow-up of #5677 for proton compiler mid-end support, focusing on op definition. Specifically, we 1. added the tablegen definitions of the proton mid-end operators, 2. removed attributes of the front-end
RecordOp(make it a true marker), 3. cleaned up the dialect's macro.