The current scheme with in-place updates of the types of values may
result in operations recognized as legal and thus preventing them from
being converted when the operations producing their operands have been
converted earlier, as their types have been updated and legality is
solely based on types.
For example, the conversion pattern for an `tensor.insert_slice`
operation working on tensors of encrypted values may not trigger if
the operations producing its operands have been converted, leaving the
operation with updated operand types with the extra dimension added by
the type conversion from TFHE to Concrete, but with unmodified sizes,
strides and offsets, not taking into account the extra dimension. This
causes the verifier of the affected operation to fail and the
compilation to abort.
By using op conversion patterns, the original types of each operation
are preserved during the actual rewrite, correctly triggering all
conversion patterns based on the legality of data types.
The reinstantianting rewrite pattern for `scf.for` operations,
`TypeConvertingReinstantiationPattern<scf::ForOp, false>`, calls
`mlir::ConversionPatternRewriter::replaceOpWithNewOp()` before moving
the operations of the original loop to the newly created loop. Since
`replaceOpWithNewOp()` indirectly marks all operations of the old loop
as ignored for dialect conversion, the dialect converter never
descends recursively into the newly created loop.
This causes operations that are illegal to be preserved, which results
in illegal IR after dialect conversion.
This commit splits the replacement into three steps:
1. Creation of the new loop via
mlir::ConversionPatternRewriter::create()`
2. Moving operations from the old loop to the newly created one
3. Replacement of the original loop with the results of the new one
via `mlir::ConversionPatternRewriter::replaceOp()`
This causes the operations of the loops not to be ignored and fixes
dialect conversion.
This commit brings support for multiple secret keys in the TFHE
dialect. In particular, a parameterized `TFHE` circuit can now be
given as input, with any combination of (semantically valid) of
ks/bs/woppbs mixing different secret keys, and compiled down to a
valid executable function, with server keys properly looked up.
Secret keys are now stateful objects which can be:
-> none/unparameterized (syntax `sk?`): The keys are in state after
the lowering from the `FHE` dialect.
-> parameterized (syntax `sk<identifier, polysize, dimension>`): The
keys were parameterized, either by user or by the optimizer. The
`identifier` field can be used to disambiguate two keys with same
`polysize` and `dimension`.
-> normalized (syntax `sk[index]<polysize, dimension>`): The keys were
attached to their index in the list of keys in the runtime context.
The _normalization_ of key indices also acts on the ksk, bsk and pksk,
which are given indices in the same spirit now.
Finally, in order to allow parameterized `TFHE` circuit to be given
as input and compiled down to executable functions, we added a way to
pass the encodings that are used to encode/decode the circuit
inputs/outputs. In the case of a compilation from the `FHE` dialect,
those informations are automatically extracted from the higher level
informations available in this dialect.
