I originally wrote the bgv-to-openfhe lowering without a complete understanding of the limitations of the OpenFHE API, which results in a decent amount of cruft related to casting types during OpenFHE codegen. For example, the input to an encode op in OpenFHE must be int64_t, but the codegen supports inputs of type int16_t and casts them in C++ generated code.
This is relatively small, but since this is part of the OpenFHE API, it would be more coherent to represent those constraints as openfhe op type constraints, and insert casting ops in the lowering from BGV to OpenFHE, and then have simpler codegen for the cast ops directly.
I originally wrote the
bgv-to-openfhe
lowering without a complete understanding of the limitations of the OpenFHE API, which results in a decent amount of cruft related to casting types during OpenFHE codegen. For example, the input to an encode op in OpenFHE must beint64_t
, but the codegen supports inputs of typeint16_t
and casts them in C++ generated code.This is relatively small, but since this is part of the OpenFHE API, it would be more coherent to represent those constraints as
openfhe
op type constraints, and insert casting ops in the lowering from BGV to OpenFHE, and then have simpler codegen for the cast ops directly.