openvino
0076e719 - [Snippets][ARM] Fixed GemmCopyB execution after kernel recompilation (#31747)

Commit
246 days ago
[Snippets][ARM] Fixed GemmCopyB execution after kernel recompilation (#31747) ### Details: - *On the master branch, kernel executor for `GemmCopyB` requires `n_block_size` which is equal to `N` dimensions from `GemmCPU` subtensors. [`jit_gemm_copy_b_emitter`](https://github.com/openvinotoolkit/openvino/blob/5e3914a1d0cf29470451ebe676c14a68386a5e94/src/plugins/intel_cpu/src/emitters/snippets/aarch64/jit_gemm_copy_b_emitter.cpp#L50) initializes this `n_block_size` and set to kernel executor config. However, if there are new shapes with new broadcast pattern (we have regenerate whole kernel), generator gets cloned `LinearIR` after previous infer requests. It means that this cloned `LinearIR` might be changed by previous infer requests. For example, subtensors of `GemmCPU` are changed by [`GemmKernelExcutor::update_config()`](https://github.com/openvinotoolkit/openvino/blob/dce9b25475826c967c8a2a121e864dc7b7cab155/src/plugins/intel_cpu/src/emitters/snippets/brgemm_generic.cpp#L174). It leads to incorrect `n_block_size` initialization in `jit_gemm_copy_b_emitter` during the next kernel regeneration. This PR removes this logic from `jit_gemm_copy_b_emitters` and set static const `n_block_size` in `GemmCopyBKernelExecutor`* - *Currently we use repacking from KleidiAI with iteration by `n_blk_size` where actually `n_blk_size` doesn't depend on `N_blk` from `GemmCPU`. It can be any value* ### Tickets: - *N/A*
Author
Parents
Loading