You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.The text was updated successfully, but these errors were encountered: