note: this cannot be done as before in the optimizer since the latter had more information.
here we assumed each input contribute equally to the resulting noise.
A better fix could be to provide the linear relation of inputs instead of manp and smanp.
This ensures that the regression fixed by
3cd3dff92a is not reintroduced, which
caused the compiler to abort in `ForLoopToParallelPass` for `scf.for`
loops with iteration arguments, even if these were marked with the
attribute `parallel` set to `false`.
The pattern converting `scf.for` operations to `scf.parallel`
operations from `lib/Transforms/ForLoopToParallel.cpp` contains an
assertion that ensures that the source operation does not have any
iteration arguments in order to keep the conversion as simple as
possible.
However, if the attribute `parallel` of the source operation is
`false`, the operation is replaced with an identical clone and the
conversion could be treated as a no-op.
This change modifies the pattern, such that it simply fails if
`parallel` is `false`, making the check for the absence of iteration
arguments unnecessary and avoiding unnecessary bailouts by the
compiler.
Also, invoke the canonicalizer to include the new canonicalization
pattern after batching in order to eliminate unnecessary copies due to
redundant insertions completely overwriting empty tensors.
The test
`end_to_end_trace.simulate1.trace_ciphertext_without_attributes_16bits.0`
generates `Tracing.trace_ciphertext` operations, which are not handled
by `SimulateTFHEPass`, resulting in a conversion error.
This change causes `Tracing.trace_ciphertext` operations to be
converted into appropriate `Tracing.trace_plaintext` operations.
previous version was not working properly (too recent). So we switched
to 11.8 and thus downgraded to gcc11. The reason for using ?= in the
Makefile is to default to gcc11 in the docker image, as those variables
are set in the env.
With the type inference pass now being able to handle RT operations
and multiple functions, the restriction disallowing data-flow
parallelization when choosing the dag-multi optimization strategy can
be lifted. Remove the check and bail out in `CompilerEngine.cpp`.
This adds support for the operations `RT.await_future`,
`RT.build_return_ptr_placeholder`, `RT.create_async_task`,
`RT.deref_return_ptr_placeholder`,
`RT.deref_work_function_argument_ptr_placeholder`,
`RT.make_ready_future`, `RT.register_task_work_function`, and
`RT.work_function_return`, the RT types `RT.ptr` and `RT.future`, as
well as the auxiliary operation `arith.select`.
The type inference pass currently only supports a single function as
it is unable to infer types across function boundaries. This commit
adds support for multiple functions and tracks types across
`func.func`, `func.call` and function `constant` operations.
A function may be referenced at multiple sites, including at locations
that have not been visited by the rewriter when the function itself is
rewritten. By using `IRRewriter::replaceOp` after rewriting a
function, the function is erased immediately, which may cause the
rewriting to fail due to remaining uses of the function.
Defering the erasure of functions to the end of the entire rewriting
process ensures that all uses of the original functions have been
updated to the rewritten functions.
Operations with regions containing multiple blocks are currently not
handled correctly, since the list of successors of an operation is not
updated with rewritten blocks when the operation is
rewritten. Furthermore, functions were assumed to have only a single
block.
This change supports operations with multiple blocks by fixing the
issues above.
Updates of the types inferred for the values related to an operation
only propagate correctly to the operation if there is a direct
producer-consumer relationship or an indirect producer-consumer
relationship via some additional mechanism (e.g., region
successors). However, this is not sufficient to ensure updates of
values and operations that are related otherwise.
This change explicitly models the dependencies between related values
and an operation via `DataFlowAnalysis::addDependency` in order to
guarantee that all updates of the types of values are propagated to
all operations that the type resolver has designated as related
operations.
Furthermore, all operations are visited once initially in order to
guarantee that updates propagate to operations, for which the dataflow
framework does not invoke `visitOperation`.
