[LPT] Quantized LSTMSequence & GRUSequence extended support

[eshoguli]

Details:

• Low Precision Transformations: Quantized LSTMSequence & GRUSequence extended support

Tickets:

• Current implementation for: CVS-146067
• Will be changed in feature request: CVS-147588

[v-Golubev]

Please remove debug info (serialization, couts) and fix the CI

[v-Golubev]

I am still concerned by the current implementation. We can merge it, but I think we need to prioritize CVS-147588 to remove this WA as soon as possible

[v-Golubev]

We still don't match on v3::Broadcast here. Maybe we can match on BroadcastBase?

[eshoguli]

We need specify supported operation here, not base types, which can be inheritted by not supported operation in future.

[v-Golubev]

We always regulate the desired precisions on inputs with PrecisionsRestriction which are set by plugin. In CPU, we actually have u8u8 restrictions:

            PrecisionsRestriction::create<ov::opset5::LSTMSequence>({
                    {{0, 1}, {ov::element::u8}}
                }),
            PrecisionsRestriction::create<ov::opset6::GRUSequence>({
                    {{0, 1}, {ov::element::u8}}
                }),

Why do we need this additional logic with precisions limitations here? If there is no chance to avoid it, could you please add an explanatory comment in the code on what undefined precision means?

[eshoguli]

We need it here.
LPT uses operation input precision restrictions to identify output precision for FakeQuantize dequantization transformation. But it doesn't mean, that we can ignore filter or input validation in each transformation pattern matching, because in Constant branch (for example, a branch with single Constant operation) LPT can not provide require precision.

[v-Golubev]

This is a valid point, but it seems like we have such checks only in this transformation. Does it mean that we must perform the checks in each transformation (or at least in the transformations which work with layers with weights)?