Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: split out simp_mem to Arm/Memory/Common [1/?] #230

Merged
merged 3 commits into from
Oct 28, 2024

Conversation

bollu
Copy link
Collaborator

@bollu bollu commented Oct 10, 2024

Description:

This will be used in the next paper to build mem_omega, which will be a finishing tactic that will use the full power of omega. simp_mem will be restricted in power to only perform rewriting, allowing us to better control omega.

Testing:

conformance succeeds

License:

By submitting this pull request, I confirm that my contribution is
made under the terms of the Apache 2.0 license.

@bollu bollu requested a review from shigoel as a code owner October 10, 2024 19:04
@bollu bollu force-pushed the simp-mem-mem-omega branch from 107c406 to d79f376 Compare October 10, 2024 19:27
@shigoel shigoel merged commit 3ac8c20 into main Oct 28, 2024
5 checks passed
@shigoel shigoel deleted the simp-mem-mem-omega branch October 28, 2024 19:52
bollu added a commit that referenced this pull request Oct 29, 2024
…ga [2/?]

This helps control how aggressive simp_mem is.

I was hoping that we would see a major performance difference. We do see some evidence for improvement in the `Experiments/MemoryAliasing.lean` (the numbers are extremely consistent across runs:

```
lake build Proofs.Experiments.MemoryAliasing  2.86s user 0.34s system 92% cpu 3.466 total

lake build Proofs.Experiments.MemoryAliasing  2.76s user 0.33s system 92% cpu 3.332 total
```

---

However, on the much larger `Memcpy.lean`, these types of considerations seem to just not matter:

```
lake build Proofs.Experiments.Memcpy.MemCpyVCG  31.79s user 0.81s system 99% cpu 32.878 total

lake build Proofs.Experiments.Memcpy.MemCpyVCG  32.79s user 0.80s system 99% cpu 33.870 total
```

This is a tad disappointing, but such is life. Onward to the next refactor. This is stacked on top of #230
bollu added a commit that referenced this pull request Oct 29, 2024
…ga [2/?]

This helps control how aggressive simp_mem is.

I was hoping that we would see a major performance difference. We do see some evidence for improvement in the `Experiments/MemoryAliasing.lean` (the numbers are extremely consistent across runs:

```
lake build Proofs.Experiments.MemoryAliasing  2.86s user 0.34s system 92% cpu 3.466 total

lake build Proofs.Experiments.MemoryAliasing  2.76s user 0.33s system 92% cpu 3.332 total
```

---

However, on the much larger `Memcpy.lean`, these types of considerations seem to just not matter:

```
lake build Proofs.Experiments.Memcpy.MemCpyVCG  31.79s user 0.81s system 99% cpu 32.878 total

lake build Proofs.Experiments.Memcpy.MemCpyVCG  32.79s user 0.80s system 99% cpu 33.870 total
```

This is a tad disappointing, but such is life. Onward to the next refactor. This is stacked on top of #230
shigoel pushed a commit that referenced this pull request Oct 29, 2024
…ga [2/?] (#231)

This helps control how aggressive `simp_mem` is, since `simp_mem` now no
longer closes memory goals, but rather expects the user to manually
invoke `mem_omega` when necessary. Another impact of this change is that
we split `mem_omega` into two tactics: `mem_omega` that does not expose
`pairwiseSeparate` goals, and `mem_omega!`, which does. This also helps
control the performance of `mem_omega`, and hopefully, this ensures that
the user is careful before exposing a full `O(n^2)` set of constraints
to the user.

--- 

I was hoping that we would see a major performance difference. We do see
some evidence for improvement in the `Experiments/MemoryAliasing.lean`
(the numbers are extremely consistent across runs:

```
### Old timings
lake build Proofs.Experiments.MemoryAliasing  2.86s user 0.34s system 92% cpu 3.466 total

### New timings
lake build Proofs.Experiments.MemoryAliasing  2.76s user 0.33s system 92% cpu 3.332 total
```

---

However, on the much larger `Memcpy.lean`, these types of considerations
seem to just not matter:

```
### Old timings
lake build Proofs.Experiments.Memcpy.MemCpyVCG  31.79s user 0.81s system 99% cpu 32.878 total

### New timings
lake build Proofs.Experiments.Memcpy.MemCpyVCG  32.79s user 0.80s system 99% cpu 33.870 total
```

This is a tad disappointing, but such is life. Onward to the next
refactor. This is stacked on top of #230
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants