Fix/improve `--ciphertext-degree` behaviour

[AlexanderViand]

First of all, --ciphertext-degree should probably be called --minimum-number-slots or similar, since that's what its currently doing..

For CKKS, we multiply it 2x to get the minimum ring degree (for BFV/BGV it's already min ring degree), but then parameter selection is free to choose a bigger ring degree.

This also means there's an implicit assumption in HEIR that anything doing rotation-based computations won't care about the difference between a 1024-length cyclical vector and, e.g., that 1024 vector being repeated a bunch of times to fill a 16k-lenght vector. For example, all of our tensor_ext.insert should write to any slot i % 1024, and not just to slot i. However, I don't think we're doing that at the moment.

[wtd2]

Agreed! That made me confused once for the CKKS scheme.

[j2kun]

First of all, --ciphertext-degree should probably be called --minimum-number-slots or similar, since that's what its currently doing..

Agree with the rename. There was a long standing issue for this but I can't find it at the moment.

This also means there's an implicit assumption in HEIR that anything doing rotation-based computations won't care about the difference between a 1024-length cyclical vector and, e.g., that 1024 vector being repeated a bunch of times to fill a 16k-lenght vector. For example, all of our tensor_ext.insert should write to any slot i % 1024, and not just to slot i. However, I don't think we're doing that at the moment.

I'm not sure I follow. I agree that when we pick a larger ring degree than the minimum slot count requested, we cyclically repeat to fill the slots and make rotation coherent, but I don't think there's a problem here. When we tensor.insert before we convert-to-ciphertext-semantics, the lowering needs to maintain consistency, so it would update all slots as per the layout. After we are in ciphertext-semantic land, tensor.insert on a secret SSA value should be illegal, and all of the other FHE ops agree with cycloc rotations. In particular, plaintext masks in shift-networks and similar are defined before the cyclic repetition logic caused by parameter selection, so those should be sound as well.

So without a specific counterexample where HEIR is compiling something incorrectly due to the expanded parameters at the backend, I would claim this issue is limited to the naming of the flag/options.

[j2kun]

This led me to rename the flag (done in #3254), so it's unclear if there's more work to do on this issue.

[AlexanderViand]

I thought I had an example of where it could go wrong @differnet slot count, but I can't come up with one any more 🤷 so maybe it is indeed safe as-is :)