Backend fails to simplify complex shift expressions with bitwise AND operations

[Stevengre]

Problem Description

We've encountered an issue where the K backend fails to simplify certain complex expressions involving bit shifts and logical operations, even when simpler variants of the same expressions work correctly.

Failing Case

The following simplification rule fails:

0 <=Int (Bytes2Int(substrBytes(W3, 8, 12), LE, Unsigned) +Int Y +Int Z &Int 4294967295) >>Int 8 => true

Working Cases

However, these similar expressions work correctly:

// This works when X is a simple variable
0 <=Int X >>Int 8 => true
  requires 0 <=Int X

// This works for the complex term without the shift
0 <=Int Bytes2Int(substrBytes(W3, 8, 12), LE, Unsigned) +Int Y +Int Z &Int 4294967295 => true

Root Cause Analysis

The backend cannot infer the complex case from the combination of the two working cases. This suggests a limitation in the theorem prover's ability to compose logical reasoning across multiple steps.

Attempted Solutions

1. SMT Lemmas: Adding smt-lemma annotations to the <=Int rules didn't resolve the issue.

Questions

1. Is there a recommended workaround for cases where the backend cannot perform multi-step logical inference?
2. What's the best way to utilize theory reasoning for complex expressions like this?

Environment

• Related to PR Smart constructors #137: Fix unsimplified bytes2int o int2bytes patterns
• File: src/tests/integration/test-data/specs/xx.k

Expected Behavior

The complex shift expression should simplify to true just like its simpler components do.

Additional Context

This issue is blocking the completion of PR #137, which aims to fix unsimplified bytes2int o int2bytes patterns in the RISC-V semantics. But we have another way to solve this issue.

[jberthold]

See discussion in runtimeverification/riscv-semantics#137 (comment)

[Stevengre]

Sorry, I'm still a bit confused after reading through the discussion. Regarding the failing pattern:

Bool2Word(0 <=Int (Bytes2Int(substrBytes(W3, 8, 12), LE, Unsigned) +Int Y +Int Z &Int 4294967295) >>Int 8) => 1

From a top-down pattern matching perspective, we first see Bool2Word(??), but we don’t know whether ?? evaluates to true or false, so we cannot directly apply the rewrite rule for Bool2Word. Therefore, we need to simplify the inner pattern:

0 <=Int (Bytes2Int(substrBytes(W3, 8, 12), LE, Unsigned) +Int Y +Int Z &Int 4294967295) >>Int 8

We already have the rule:

rule [int-rhs-ineq]: 0 <=Int A >>Int B => true
  requires 0 <=Int A andBool 0 <=Int B
  [simplification]

Here, B = 8, which is clearly non-negative. So now we need to determine whether A is non-negative:

0 <=Int Bytes2Int(substrBytes(W3, 8, 12), LE, Unsigned) +Int Y +Int Z &Int 4294967295

We also have the following rules:

rule [int-and-ineq]: 0 <=Int A &Int B => true
  requires 0 <=Int A andBool 0 <=Int B
  [simplification]

rule [int-add-ineq-0]: 0 <=Int A +Int B => true
  requires 0 <=Int A andBool 0 <=Int B
  [simplification]

Therefore, we can conclude that:

Bool2Word(0 <=Int Bytes2Int(substrBytes(W3, 8, 12), LE, Unsigned) +Int Y +Int Z &Int 4294967295) => 1

should be valid. This result can then feed back into the application of int-rhs-ineq, allowing the whole expression to be rewritten to true.

What I'm not clear about is how the backend is currently executing the simplification. It seems to successfully rewrite the simpler expression:

Bool2Word(0 <=Int Bytes2Int(...) +Int Y +Int Z &Int 4294967295) => 1

but fails on the slightly more complex one involving the right shift:

Bool2Word(0 <=Int (Bytes2Int(...) +Int Y +Int Z &Int 4294967295) >>Int 8) => 1

Let me know if I misunderstood anything or if additional configuration is required to enable this simplification.