zeekay
b832ba2c39
Forked from upstream concrete (BSD-3-Clause-Clear, © 2024 ZAMA) at HEAD
ecb729bb. Modifications copyright © 2026 Lux Industries Inc.
Rebranding scope:
- Python module concrete → torus (across frontends/torus-python)
- Rust module concrete-* → torus-* (across frontends/torus-rust)
- MLIR dialect concretelang → toruslang (across compilers/torus-compiler)
- Compiler optimizer concrete-optimizer → torus-optimizer
- Backend concrete-cpu / concrete-cuda → torus-cpu / torus-cuda
- Wire protocol concrete-protocol → torus-protocol
- Parameter-curves concrete-security-curves-* → torus-security-curves-*
- Public symbols concretelib → toruslib, ConcreteLang → TorusLang
- URLs github.com/zama-ai/concrete → github.com/luxfhe/torus
- URLs docs.zama.ai/concrete → docs.luxfhe.com/torus
Legal compliance:
- LICENSE.txt retains original Copyright © 2024 ZAMA verbatim (§1-§2)
- LICENSE.txt adds modifications copyright © 2026 Lux Industries Inc.
- §3 endorsement clause: Torus is marketed exclusively as a Lux product;
no Zama name used in README, docs, or marketing
- NOTICE file provides factual attribution per legal best practice
(not endorsement; required by upstream BSD-3-Clause-Clear)
README + NOTICE rewritten from scratch with Lux brand:
- Quick-start in Python (torus.fhe)
- Architecture diagram showing the gen-1 vtbl integration path
(luxcpp/gpu → lux-private/gpu-kernels for CUDA/Metal/WebGPU)
- Scheme coverage table: TFHE (luxfi/fhe), CKKS/BGV/BFV (luxfi/lattice)
- Lux FHE family table: Torus / TorusVM / TorusEVM / TorusML / TorusNet
Known limitations (phase-2A scope):
- PyPI package torus-fhe not yet published; the torus Python module
is renamed structurally but pip-installable distribution is a
follow-up (Phase 2A.1)
- MLIR dialect rename is text-level; the compiler-internal LLVM
rebuild (concrete-compiler-internal-llvm-project submodule) is
structural and works; tablegen files renamed concrete→torus but the
generated .inc files in the source tree will regenerate at build
time
- backends/torus-cuda/implementation/ is an upstream submodule
pointer to the tfhe-rs source (not fetched in the staging clone);
the CUDA backend body is delivered out-of-tree
- ~100 test-fixture variable names like concrete_encoded_sample
retain "concrete" as a math term (vs symbolic); these are inside
tests/, not the public API; cleanup is a follow-up commit
- 295 Python `from concrete import ...` residuals in luxfhe/ml-sdk
consumer remain; that repo's import update is Phase 2B
This commit is the seed for the luxfhe/torus repo. Push as the first
commit to a fresh GitHub repo; do not re-import upstream Zama git
history.
6.2 KiB
'RT' Dialect
Runtime dialect A dialect for representation the abstraction needed for the runtime.
Operation definition
RT.await_future (::mlir::toruslang::RT::AwaitFutureOp)
Wait for a future and access its data.
The results of a dataflow task are always futures which could be
further used as inputs to subsequent tasks. When the result of a task
is needed in the outer execution context, the result future needs to
be synchronized and its data accessed using RT.await_future.
Operands:
| Operand | Description |
|---|---|
input |
Future with a parameterized element type |
Results:
| Result | Description |
|---|---|
output |
any type |
RT.build_return_ptr_placeholder (::mlir::toruslang::RT::BuildReturnPtrPlaceholderOp)
Results:
| Result | Description |
|---|---|
output |
Pointer to a parameterized element type |
RT.clone_future (::mlir::toruslang::RT::CloneFutureOp)
Interfaces: AllocationOpInterface, MemoryEffectOpInterface
Operands:
| Operand | Description |
|---|---|
input |
Future with a parameterized element type |
Results:
| Result | Description |
|---|---|
output |
Future with a parameterized element type |
RT.create_async_task (::mlir::toruslang::RT::CreateAsyncTaskOp)
Create a dataflow task.
Attributes:
| Attribute | MLIR Type | Description |
|---|---|---|
workfn |
::mlir::SymbolRefAttr | symbol reference attribute |
Operands:
| Operand | Description |
|---|---|
list |
any type |
RT.dataflow_task (::mlir::toruslang::RT::DataflowTaskOp)
Dataflow task operation
RT.dataflow_task allows to specify a task that will be concurrently
executed when their operands are ready. Operands are either the
results of computation in other RT.dataflow_task (dataflow
dependences) or obtained from the execution context (immediate
operands). Operands are synchronized using futures and, in the case
of immediate operands, copied when the task is created. Caution is
required when the operand is a pointer as no deep copy will occur.
Example:
func @test(%0 : i64): (i64, i64) {
// Execute right now as %0 is ready.
%1, %2 = "RT.dataflow_task"(%0) ({
%a = addi %0, %0 : i64
%b = muli %0, %0 : i64
"RT.dataflow_yield"(%a, %b) : (i64, i64) -> i64
}) : (i64, i64) -> (i64, i64)
// Concurrently execute both tasks below when the task above is completed.
%3 = "RT.dataflow_task"(%1) ({
%c = constant 1 : %i64
%a = addi %1, %c : i64
"RT.dataflow_yield"(%a) : (i64, i64) -> i64
}) : (i64, i64) -> (i64, i64)
%4 = "RT.dataflow_task"(%2) ({
%c = constant 2 : %i64
%a = addi %2, %c : i64
"RT.dataflow_yield"(%a) : (i64, i64) -> i64
}) : (i64, i64) -> (i64, i64)
return %3, %4 : (i64, i64)
}
Traits: AutomaticAllocationScope, SingleBlockImplicitTerminator
Interfaces: AllocationOpInterface, MemoryEffectOpInterface, RegionBranchOpInterface
Operands:
| Operand | Description |
|---|---|
inputs |
any type |
Results:
| Result | Description |
|---|---|
outputs |
any type |
RT.dataflow_yield (::mlir::toruslang::RT::DataflowYieldOp)
Dataflow yield operation
RT.dataflow_yield is a special terminator operation for blocks inside the region
in RT.dataflow_task. It allows to specify the return values of a RT.dataflow_task.
Example:
%0 = constant 1 : i64
%1 = constant 2 : i64
"RT.dataflow_yield" %0, %1 : i64, i64
Traits: ReturnLike, Terminator
Operands:
| Operand | Description |
|---|---|
values |
any type |
RT.deallocate_future_data (::mlir::toruslang::RT::DeallocateFutureDataOp)
Operands:
| Operand | Description |
|---|---|
input |
Future with a parameterized element type |
RT.deallocate_future (::mlir::toruslang::RT::DeallocateFutureOp)
Operands:
| Operand | Description |
|---|---|
input |
any type |
RT.deref_return_ptr_placeholder (::mlir::toruslang::RT::DerefReturnPtrPlaceholderOp)
Operands:
| Operand | Description |
|---|---|
input |
Pointer to a parameterized element type |
Results:
| Result | Description |
|---|---|
output |
Future with a parameterized element type |
RT.deref_work_function_argument_ptr_placeholder (::mlir::toruslang::RT::DerefWorkFunctionArgumentPtrPlaceholderOp)
Operands:
| Operand | Description |
|---|---|
input |
Pointer to a parameterized element type |
Results:
| Result | Description |
|---|---|
output |
any type |
RT.make_ready_future (::mlir::toruslang::RT::MakeReadyFutureOp)
Build a ready future.
Data passed to dataflow tasks must be encapsulated in futures,
including immediate operands. These must be converted into futures
using RT.make_ready_future.
Interfaces: AllocationOpInterface, MemoryEffectOpInterface
Operands:
| Operand | Description |
|---|---|
input |
any type |
memrefCloned |
any type |
Results:
| Result | Description |
|---|---|
output |
Future with a parameterized element type |
RT.register_task_work_function (::mlir::toruslang::RT::RegisterTaskWorkFunctionOp)
Register the task work-function with the runtime system.
Operands:
| Operand | Description |
|---|---|
list |
any type |
RT.work_function_return (::mlir::toruslang::RT::WorkFunctionReturnOp)
Operands:
| Operand | Description |
|---|---|
in |
any type |
out |
any type |
Type definition
FutureType
Future with a parameterized element type
The value of a !RT.future type represents the result of an asynchronous operation.
Examples:
!RT.future<i64>
Parameters:
| Parameter | C++ type | Description |
|---|---|---|
| elementType | Type |
PointerType
Pointer to a parameterized element type
Parameters:
| Parameter | C++ type | Description |
|---|---|---|
| elementType | Type |