jli-melchior wrote: > 1. Can we get a bit more PR description? Maybe examples of where you'd be > using this? > 2. If you're going to have a bit that fiddles with instruction behavior like > that, either just make that a separate immarg (probably the cleanest way to > do it) or shove it somewhere like bit 31. Consider the possibility of more > banks. > 3. ... goodness having this weird little hint that doesn't propagate facts > about the value is going to lead to a stack of missed optimizations. Are we > _sure_ we need this?
Hi @krzysz00 thanks for review :) 1. Use case: Thanks I will add more PR description later. and the example use case is [attention kernels on gfx1250 ](https://github.com/jli-melchior/speedKernel/blob/689aaeca7cea7197b9dfc067e8d9564c0fbd1e67/attention/fmha_hd192_gfx1250/fmha_utils.py#L360) with wmma co-execution. The 1024 vgpr is split into 4 banks and if the set_msb instruction too much in the wmma co-execution window, there will be some cycle cost and hurts the performance. By pining values to specific banks with this hint we can reduce the bank switches and see significant performance gains on our attention kernels. 2. separate immarg for strict: I will split the strict flag into a separate immarg as you suggest. 3. missed optimizations: Valid concern. In practice though, the performance gain from eliminating bank switches during WMMA co-execution significantly may outweighs the missed optimization. https://github.com/llvm/llvm-project/pull/227953 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
