I was on a quest to simplify an IR that had a trivial scf.if statement. This was generated from the matvec kernel when loops were preserved. This was present to ensure that the loop indices access valid matrix diagonals -
|
auto newInnerSum = NodeTy::ifElse( |
All I thought I had to do was add the upstream integer range optimizations to simplify the if condition to be true, and then the if branch inlining pattern that inline the if branch when the statement is true. This was added in convert to ciphertext semantics:
// Use integer range optimizations to fold away always-true if conditions.
// Kernels generate this to check that index values are in bounds, but if
// the upper bound of the index value is always less than the bound, it
// should be canonicalized.
arith::populateIntRangeOptimizationsPatterns(cleanupPatterns2, solver);
populateRegionBranchOpInterfaceInliningPattern(
cleanupPatterns2, scf::IfOp::getOperationName());
When I run this, I end up segfaulting on the integer range analysis - this expects to get the storage values from the data types, but when it sees a secret data type, it defaults to a 0 but width storage. when it simulates operations between the secret types descended block arg, it hits a segfault assertion error in APInt that you can't perform an operation between mismatched type widths.
Just tracking this, and I'll upload a small commit with the code...
I don't really want to update MLIR upstream, and I played around a little with updating the interfaces that the analysis can use on secret.generic, but no luck yet.
I was on a quest to simplify an IR that had a trivial scf.if statement. This was generated from the matvec kernel when loops were preserved. This was present to ensure that the loop indices access valid matrix diagonals -
heir/lib/Kernel/KernelImplementation.h
Line 313 in 0443466
All I thought I had to do was add the upstream integer range optimizations to simplify the if condition to be true, and then the if branch inlining pattern that inline the if branch when the statement is true. This was added in convert to ciphertext semantics:
When I run this, I end up segfaulting on the integer range analysis - this expects to get the storage values from the data types, but when it sees a secret data type, it defaults to a 0 but width storage. when it simulates operations between the secret types descended block arg, it hits a segfault assertion error in APInt that you can't perform an operation between mismatched type widths.
Just tracking this, and I'll upload a small commit with the code...
I don't really want to update MLIR upstream, and I played around a little with updating the interfaces that the analysis can use on secret.generic, but no luck yet.