Use mutable/in-place operations in OpenFhePkeEmitter where possible
- Dominant language
- MLIR
- Stars
- 906
- Forks
- 171
- Avg merge
- 4d 12h
- Merged PRs (30d)
- 32
Description
In addition to the `eval<...>` functions, OpenFHE also provides `eval<...>InPlace` which overrides one of the operands,
There's also `eval<...>Mutable` where it will do any necessary preprocessing (e.g., rescaling/etc) of the operands in-place,
and `eval<...>MutableInPlace`, where it will do both the preprocessing and the operation in-place.
The plain `eval<...>` *always* forces a copy, `eval<...>InPlace` can still force a copy if pre-processing is necessary (as it's only allowed to modify/overwrite one operand), while `eval<...>MutableInPlace` will never cause copies. Since we know if an SSA value has other uses*, we should be able to determine fairly easily in `printEvalMethod` if a given op can be lowered to one of the more efficient versions.
For small "toy" programs, the performance differences are very much negligible, but for larger real-world workloads, memory tends to become a significant bottleneck, so doing this "correctly" should be beneficial. Filing this as an issue, rather than putting together a PR, as it's just not very critical at the moment 😉 |
*Thinking about this again, `hasOneUse()` is correct but too conservative, as we don't care about *prior* uses. But MLIR's Liveness analysis has `isDeadAfter` which sounds like exactly what we want.
Contributor guide
Assessment
This issue has not been assessed yet.