Reconsider "application data" field on LWE ciphertext

[j2kun]

Now that we have (nearly) completed the packing system, the application_data attribute on an LWE ciphertext type is currently only used for the debug handler framework, so that the debug handler can understand how to unpack to print cleartext values.

With the changes in https://github.com/google/heir/pull/2199 to use multi-packed ciphertexts by default, the best we will be able to do with this attribute is to print the packed cleartext values (because the remainder of the logic of how to unpack is not present on the LWE ciphertext type).

We should remove the application data field, and instead adapt the debug handler framework so that it is aware of the new layout system, and insert secret.reveal/tensor_ext.unpack ops appropriately that can be lowered automatically.

[asraa]

I agree that the shapes of the application data can be inferred from the packing, but do we still need to hold on to the underlying data type? I would keep this open until we do some non-trivial type casting, e.g. from an i32 quantized model to an f32 CKKS model. But maybe that still doesn't change anything in the system? Maybe just for evaluations?

[j2kun]

That is a good point, I hadn't considered something like encoding i64 in i16 as part of this, but it would be required to enable the full unpacking/decoding in the debug helper

[github-actions[bot]]

This issue has 2 outstanding TODOs:

• lib/Dialect/Secret/Conversions/SecretToBGV/SecretToBGV.cpp:158: this is where we are forced to use the packed cleartexts
• lib/Dialect/Secret/Conversions/SecretToCKKS/SecretToCKKS.cpp:160: this is where we are forced to use the packed cleartexts

This comment was autogenerated by todo-backlinks