Added push(...) and pop(...) for SIMD registers

[lohika-denis-kotov]

Description

Added push(...) and pop(...) for SIMD registers

[lohika-denis-kotov]

@ceciliapeng2011 @dmitry-gorokhov @maxnick @nshchego Could you please review this PR or assign reviewers ?

[maxnick]

@lohika-denis-kotov , do we really need to place those changes in oneDNN fork? M.b. we can locate them in the new jit_kernel_base class?

[lohika-denis-kotov]

@maxnick

@lohika-denis-kotov , do we really need to place those changes in oneDNN fork? M.b. we can locate them in the new jit_kernel_base class?

Yes, it could be located in new jit_kernel_base.
I just do not understand when we should push either in openvino/oneDNN or in openvino repo ?

[maxnick]

@maxnick

@lohika-denis-kotov , do we really need to place those changes in oneDNN fork? M.b. we can locate them in the new jit_kernel_base class?

Yes, it could be located in new jit_kernel_base. I just do not understand when we should push either in openvino/oneDNN or in openvino repo ?

The main idea is to keep in the fork as less changes as possible. Keeping less changes in the fork helps to easily move to new versions of oneDNN. The uni_ instructions are kept in the fork by historical reasons. Thanks to your team, we will adopt our own jit kernel base classes where we can locate all the stuff we need to write our own jit kernels. So, in my understanding, until we change some oneDNN code, it is better to keep changes in the main repo. For example, if we used the push/pop instructions to modify oneDNN jit_kernels, then it would make sense to introduce the changes to the fork.

[lohika-denis-kotov]

@maxnick

@maxnick

@lohika-denis-kotov , do we really need to place those changes in oneDNN fork? M.b. we can locate them in the new jit_kernel_base class?

Yes, it could be located in new jit_kernel_base. I just do not understand when we should push either in openvino/oneDNN or in openvino repo ?

The main idea is to keep in the fork as less changes as possible. Keeping less changes in the fork helps to easily move to new versions of oneDNN. The uni_ instructions are kept in the fork by historical reasons. Thanks to your team, we will adopt our own jit kernel base classes where we can locate all the stuff we need to write our own jit kernels. So, in my understanding, until we change some oneDNN code, it is better to keep changes in the main repo. For example, if we used the push/pop instructions to modify oneDNN jit_kernels, then it would make sense to introduce the changes to the fork.

I've already have a PR with uni_* instructions fixes that requires all this push and pop instructions.
Without them it would be harder to fix, see:
#149

[lohika-denis-kotov]

@maxnick

The main idea is to keep in the fork as less changes as possible. Keeping less changes in the fork helps to easily move to new versions of oneDNN. ...

As for me, it is better to have fast cycle for update in oneAPI/oneDNN

[lohika-denis-kotov]

Closed in favor of #149