Add orion entry dialect

[j2kun]

Fixes #2328

This corresponds to 3a09186eef73f046d4eff1f32e6ba58f4c8da349 which runs orion and exports ckks + orion dialect MLIR.

From that project, after installing deps, I ran

python examples/mlp.py
python examples/resnet.py  # needs like 60GiB of RAM or lots of swap space, takes about 5m

Then ran the result through heir-opt with this PR (which just extracted type aliases), and persisted the result to the lit tests in this PR

[j2kun]

CC @eymay

[eymay]

Thanks for adding Orion frontend support. The PR looks clean to me, I pointed out some limitations of the translator in comments.

[j2kun]

@eymay I did find it a bit strange that all the chebyshev ops emitted have a domain start/end as -1, 1 exactly, rather than some domain specific to the network/data distribution. Is that what you observed as well? Or does it indicate a bug on my part?

[j2kun]

@eymay sorry to keep bugging you again, but I also noticed that the bsgs_ratio is always 2, and I can't find anywhere in the Orion codebase that sets this value to a non-hard-coded-2. Did you notice the same?

[eymay]

@eymay I did find it a bit strange that all the chebyshev ops emitted have a domain start/end as -1, 1 exactly, rather than some domain specific to the network/data distribution. Is that what you observed as well? Or does it indicate a bug on my part?

I think this is a desired result from the Orion compilation, this is to ensure a stable polynomial approximation. So Orion normalizes the data distribution for polynomial approximation, from the Orion paper:

Range estimation: Both high-precision bootstrapping and
high-degree (Chebyshev) polynomial activation functions
require the inputs to be in the range [−1, 1].
Prior work chooses per network scaling factors by man-
ually inspecting and tracking the largest intermediate val-
ues seen [41, 52]. Orion handles this process automatically
through net.fit(), which accepts the entire training dataset
as input, calculates per layer scaling factors, and inserts scale-
down multiplications directly into the computational graph.

My default approach for the attributes in the Orion internal IR was to preserve them in the MLIR IR so they become explicit even if we don't end up using them.

[eymay]

@eymay sorry to keep bugging you again, but I also noticed that the bsgs_ratio is always 2, and I can't find anywhere in the Orion codebase that sets this value to a non-hard-coded-2. Did you notice the same?

Please I appreciate the discussion. Yes Orion seems to just keep bsgs_ratio=2 for all the layers like Linear, AvgPool2d and Conv2d. On top of that the translator also emits the same number if there is no attribute found for the op. The ratio plugs into Lattigo's LogBabyStepGiantStepRatio parameter explained here. It seems like a heuristic number that stayed on but we don't need to take it into account while lowering.

[j2kun]

Ok, one change I want to make before this PR is submitted is to have the plaintext arguments be cleartext-typed, so that the function encodes them as plaintexts at runtime. This is not optimal, but we need the ability to rotate the plaintexts for the purpose of BSGS (to my knowledge none of these libraries support rotating an encoded plaintext; decoding just to rotate and re-encode seems silly). While we could pre-rotate the diagonals Orion produces in a manner specific to HEIR's implementation of BSGS, it seems quite brittle, and I suspect the runtime hit will not be that bad...