Most of the targets in `Makefile` do not deped on files produced by
other targets and use target names solely for dependency
management. Make all such targets PHONY in order to avoid that they
are skipped accidentially when a file with the same name is present.
The Makefile target `python-bindings` invokes CMake with multiple
targets specified after the `--target` commandline option. However, as
per the CMake manpage, only one target may be specified at once.
This changes the single invocation of CMake to separate invocations
for each target.
Tested with CMake version 3.13.4.
The target `build` creates a build directory with the same name and
initializes through an invocation of CMake. Regardless of the success
or failure of the CMake invocation, all subsequent invocations of the
target do not invoke CMake anymore, as the target's prerequisites are
satisfied through the existence of the build directory created upon
the first invocation.
This patch changes the dependencies to the build directory with an
intermediate target that depends on a stamp file that is only created
when the first CMake invocation in the build directory succeeds.
- Docker image to build wheels for linux_x86_64 CPython 3.[8,9,10] with
GLIBC >= 2.24
- Specify which Python to use in Makefile
- Fix cmake build to handle when libpython isn't available (cmake>3.18)
We decide to make this choice as they are issue to crate tensor of custom integer type in python.
+ we don't do the integer extension before convert to the concrete CAPI that requires i64
LLVM errors should be handled/consumed. Creating a new one and leaving
the previous one alive will crash the compiler. Whenever we don't want a
crash (e.g. logging the error is enough), but still wanna continue the
execution, we can just consume it.
This replaces the default FHE circuit constrains (maximum encrypted
integer width of 7 bits and a Minimal Arithmetic Noise Padding of 10
with the results of the `MaxMANP` pass, which determines these values
automatically from the input program.
Since the maximum encrypted integer width and the maximum value for
the Minimal Arithmetic Noise Padding can only be derived from HLFHE
operations, the circuit constraints are determined automatically by
`zamacompiler` only if the option `--entry-dialect=hlfhe` was
specified.
For lower-level dialects, `zamacompiler` has been provided with the
options `--assume-max-eint-precision=...` and `--assume-max-manp=...`
that allow a user to specify the values for the maximum required
precision and maximum values for the Minimal Arithmetic Noise Padding.
A value of 1 is perfectly valid for the 2-norm of the constant vector
of a dot operation. Hence, the log2 of that value of 0 is also
perfectly valid. However, the offset of -1 in `getV0Parameter` applied
to that value yields an offset into a static lookup table of -1, which
triggers a segmentation fault.
This patch removes the offset of -1 for the log2 value of the 2-norm
in `getV0Parameter`.
This pass calculates the squared Minimal Arithmetic Noise Padding
(MANP) for each operation using the MANP pass and extracts the maximum
(non-squared) Minimal Arithmetic Noise Padding and the maximum
ecrypted integer width from.
This adds tests for the Minimal Arithmetic Noise Padding analysis pass
that is invoked with --debug-manp, testing both elementary operations
and DAGs of computations on encrypted integers.
The new option --acion=dump-hlfhe-manp invokes the Minimal Arithmetic
Noise Padding Analysis pass based on the squared 2-norm metric from
`lib/Dialect/HLFHE/Analysis/MANP.cpp` and dumps the module afterwards
with an extra attribute `MANP` for each HLFHE operation.
This pass calculates the squared Minimal Arithmetic Noise Padding
(MANP) for each operation of a function and stores the result in an
integer attribute named "sqMANP". This metric is identical to the
squared 2-norm of the constant vector of an equivalent dot product
between a vector of encrypted integers resulting directly from an
encryption and a vector of plaintext constants.
The pass supports the following operations:
- HLFHE.dot_eint_int
- HLFHE.zero
- HLFHE.add_eint_int
- HLFHE.add_eint
- HLFHE.sub_int_eint
- HLFHE.mul_eint_int
- HLFHE.apply_lookup_table
If any other operation is encountered, the pass conservatively
fails. The pass further makes the optimistic assumption that all
values passed to a function are either the direct result of an
encryption of a noise-refreshing operation.
This refactoring commit restructures the compilation pipeline of
`zamacompiler`, such that it is possible to enter and exit the
pipeline at different points, effectively defining the level of
abstraction at the input and the required level of abstraction for the
output.
The entry point is specified using the `--entry-dialect`
argument. Valid choices are:
`--entry-dialect=hlfhe`: Source contains HLFHE operations
`--entry-dialect=midlfhe`: Source contains MidLFHE operations
`--entry-dialect=lowlfhe`: Source contains LowLFHE operations
`--entry-dialect=std`: Source does not contain any FHE Operations
`--entry-dialect=llvm`: Source is in LLVM dialect
The exit point is defined by an action, specified using --action.
`--action=roundtrip`:
Parse the source file to in-memory representation and immediately
dump as text without any processing
`--action=dump-midlfhe`:
Lower source to MidLFHE and dump result as text
`--action=dump-lowlfhe`:
Lower source to LowLFHE and dump result as text
`--action=dump-std`:
Lower source to only standard MLIR dialects (i.e., all FHE
operations have already been lowered)
`--action=dump-llvm-dialect`:
Lower source to MLIR's LLVM dialect (i.e., the LLVM dialect, not
LLVM IR)
`--action=dump-llvm-ir`:
Lower source to plain LLVM IR (i.e., not the LLVM dialect, but
actual LLVM IR)
`--action=dump-optimized-llvm-ir`:
Lower source to plain LLVM IR (i.e., not the LLVM dialect, but
actual LLVM IR), pass the result through the LLVM optimizer and
print the result.
`--action=dump-jit-invoke`:
Execute the full lowering pipeline to optimized LLVM IR, JIT
compile the result, invoke the function specified in
`--jit-funcname` with the parameters from `--jit-args` and print
the functions return value.
The function `getV0Parameter()` returns a pointer to a static array,
which is not intended to be mutable. Reflect this in the return type
of the function.
Replace the macros `LOG_VERBOSE` and `LOG_ERROR` with C++-style
streams retrieved through `log_verbose()` and `log_error()`. This
aligns with the `MLIR` infrastructure and avoids pollution of the
global namespace through a common header file in subsequent
refactoring commits splitting the functionality of `src/main.cpp` into
multiple files.
output size of keyswiting wasn't set properly. As this information must
come from the selected parameters, it should goes down from the MidLFHE
to the appropriate call to ciphertext allocation
