[OP][CPU] Fix SliceScatter issues with non-constant slice params

[mmikolajcz]

Details:

• SliceScatter could experience failures caused by not calling prepareParams() depending on input and execution type
• Fix issue in calling get_raw_data in shape_inference on empty tensors

Tickets:

• CVS-156349

[mitruska]

The same logic could be implemented without duplication of the !execPtr check.
As the comment is related to the SliceScatter op, shouldn't the attrs.isSliceScatterOp be checked as well?
Also is there a chance that the prepareParams will not initialize the execPtr and it will be still a nullptr after?

Suggested change

	if (!execPtr && !Node::isDynamic) {
	// SliceScatter due to not having data dependency on shape may not call prepareParams when start/stop/step values are non-constant in Static execution.
	StridedSlice::prepareParams();
	} else if (!execPtr) {
	if (!execPtr) {
	if (attrs.isSliceScatterOp && !isDynamicNode()) {
	// SliceScatter due to not having data dependency on shape may not call prepareParams when start/stop/step values are non-constant in Static execution.
	StridedSlice::prepareParams();
	} else {
	OPENVINO_THROW(errorPrefix, "doesn't have compiled executor!");

Is it a final solution or temp fix for the issue described in the comment?

[mmikolajcz]

Checking for isSliceScatter op may not be needed, instead it would make more sense to check for const inputs. for start/stop/step.
For other slice ops prepareParams is called in 2 ways:

1. If params are const then prepareParams will be called by createPrimitive,
2. If params are not const, createPrimitive will not be called, however since Slice/StridedSlice requires values from params to determine output shape, this node will be dynamic, thus it will call prepareParams in updateDynamicParams

In SliceScatter there is a problem with option 2 because output shape doesn't depend on data. So this would be an workaround for case where all inputs would have static shapes (node is static so no updateDynamicParams) and start/stop/step would be non-constant (prepareParams cannot be called during createPrimitive due to depending on const value).

As for final solution, I guess it may benefit from some changes to StridedSliceCommonExecutor since with static shapes, some calculations could be prepared in createPrimitive stage.

[dmitry-gorokhov]

@maxnick Could you please take a look from CPU side?

[praasz]

LGTM shape inference core part.

[maxnick]

@mitruska , do you have any further comments or suggestions?

[mitruska]

@mitruska , do you have any further comments or suggestions?

No further comments

[maxnick]

If the data on the corresponding inputs are not constant, it means that the executor must be reinitialized every inference call, as the data in variables may be updated each inference. If the tests pass, that means that either the test converge is still not sufficient, or there is no real data dependency and the executor may be created at the compilation stage.

[maxnick]

Could you please elaborate on the reason behind introducing this check? It looks like the current test configuration doesn't provide null pointers. But if it does, an input tensor is created but not initialized with valid values. So what is the expectation of using such an input?

[maxnick]

Actually this is the reason why the tests don't cover the main issue, as is being resolved in this PR. The thing is that the SL tests in the static shapes configuration perform only one inference, thus the values on the variable inputs don't really change from infer to infer and SL tests don't spot the issue. But if we had had such tests, they would have revealed the design flaw of the current solution solution (please see the comment regarding execute method implementation). So apparently the SL tests should be extended to cover such a use case: the values on the variable inputs actually changes each inference. To this end even a dedicated test class may be introduced, when necessary.

[github-actions]

This PR will be closed in a week because of 2 weeks of no activity.