Add uni_gatherdps and uni_scatterdps

[lohika-denis-kotov]

Description

This PR adds uni_gatherdps and uni_scatterdps for simplifying writing kernels.
Consider the following usage of this operations:

uni_vgatherdps(vmm_load_value0, reg_load_value0_ptr, vmm_delta_idx, sizeof(float), 0, vmm_load_value0_mask);
uni_vgatherdps(vmm_load_value1, reg_load_value1_ptr, vmm_delta_idx, sizeof(float), 0, vmm_load_value1_mask);
uni_vgatherdps(vmm_load_value2, reg_load_value2_ptr, vmm_delta_idx, sizeof(float), 0, vmm_load_value2_mask);
uni_vgatherdps(vmm_load_value3, reg_load_value3_ptr, vmm_delta_idx, sizeof(float), 0, vmm_load_value3_mask);

...

uni_vscatterdps(vmm_store_value0, reg_store_value0_ptr, sizeof(float), 0, vmm_value0, vmm_store_value0_mask);
uni_vscatterdps(vmm_store_value1, reg_store_value1_ptr, sizeof(float), 0, vmm_value1, vmm_store_value1_mask);
uni_vscatterdps(vmm_store_value2, reg_store_value2_ptr, sizeof(float), 0, vmm_value2, vmm_store_value2_mask);
uni_vscatterdps(vmm_store_value3, reg_store_value3_ptr, sizeof(float), 0, vmm_value3, vmm_store_value3_mask);

[lohika-denis-kotov]

@dmitry-gorokhov Please, take a look at this PR and assign reviewers

[avoskoboinyk-lohika]

Shouldn't we apply reg_mask here, in addition to xmm_val in vgatherdps()?

[lohika-denis-kotov]

No, according the documentation the reg_mask will be applied implicitly, see section:
https://www.felixcloutier.com/x86/vgatherdps:vgatherdpd#instruction-operand-encoding

[ceciliapeng2011]

If I understand correctly, we are going to do onednn reduction, to move functions from onednn to openvino. @dmitry-gorokhov would you please give some guideline on these custom instructions?

[dmitry-gorokhov]

I am ok to merge here simple uni_* mnemonics which actual serve here as pure wrappers to map register type on correct instruction. Once base generator class for all CPU Plugin Jit kernels is introduced we will be able to move all this custom mnemonics into CPU plugin codebase.

Here is different situation. Gather/Scatter mnemonics are complex and contain complicated logic of emulation for legacy ISA and registers allocation. My recommendation for such cases is to implement the logic under jit_emitter hierarchy and put into CPU plugin codebase. You can use Load Emitter as an example since it is widely used in the plugin.
As an advantage Emitter solves task of auxiliary registers allocation. All you need to do is to specify required number of vector registers or general-purpose registers and then easily use them on implementation level. Preamble/Postamble logic guarantees that state of allocated registers will be preserved and an emitter can be safely called inside JIT kernel.

[ceciliapeng2011]

I am ok to merge here simple uni_* mnemonics which actual serve here as pure wrappers to map register type on correct instruction. Once base generator class for all CPU Plugin Jit kernels is introduced we will be able to move all this custom mnemonics into CPU plugin codebase.

Here is different situation. Gather/Scatter mnemonics are complex and contain complicated logic of emulation for legacy ISA and registers allocation. My recommendation for such cases is to implement the logic under jit_emitter hierarchy and put into CPU plugin codebase. You can use Load Emitter as an example since it is widely used in the plugin. As an advantage Emitter solves task of auxiliary registers allocation. All you need to do is to specify required number of vector registers or general-purpose registers and then easily use them on implementation level. Preamble/Postamble logic guarantees that state of allocated registers will be preserved and an emitter can be safely called inside JIT kernel.

@avoskoboinyk-lohika @lohika-denis-kotov Do you have more questions about this recommendation?

[lohika-denis-kotov]

I am closing this PR.
Moved all bits of implementation in 2 separate PRs:
openvinotoolkit/openvino#12991
#148