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

feat[venom]: mark loads as non-volatile #4388

Open
wants to merge 49 commits into
base: master
Choose a base branch
from

Conversation

charles-cooper
Copy link
Member

this commit marks load instructions (mload, sload, etc) as non-volatile, allowing them to be removed in the
remove_unused_variables pass.

What I did

How I did it

How to verify it

Commit message

Commit message for the final, squashed PR. (Optional, but reviewers will appreciate it! Please see our commit message style guide for what we would ideally like to see in a commit message.)

Description for the changelog

Cute Animal Picture

Put a link to a cute animal picture inside the parenthesis-->

this commit marks load instructions (`mload`, `sload`, etc) as
non-volatile, allowing them to be removed in the
`remove_unused_variables` pass.
Copy link

codecov bot commented Dec 4, 2024

Codecov Report

Attention: Patch coverage is 33.33333% with 36 lines in your changes missing coverage. Please review.

Project coverage is 48.99%. Comparing base (9c98b3e) to head (d580116).

Files with missing lines Patch % Lines
vyper/venom/analysis/reachable.py 40.00% 15 Missing ⚠️
vyper/ir/compile_ir.py 0.00% 6 Missing and 1 partial ⚠️
vyper/venom/venom_to_assembly.py 0.00% 6 Missing ⚠️
vyper/venom/passes/remove_unused_variables.py 50.00% 4 Missing ⚠️
vyper/venom/analysis/cfg.py 0.00% 2 Missing ⚠️
vyper/codegen/module.py 0.00% 1 Missing ⚠️
vyper/utils.py 50.00% 1 Missing ⚠️

❗ There is a different number of reports uploaded between BASE (9c98b3e) and HEAD (d580116). Click for more details.

HEAD has 136 uploads less than BASE
Flag BASE (9c98b3e) HEAD (d580116)
140 4
Additional details and impacted files
@@             Coverage Diff             @@
##           master    #4388       +/-   ##
===========================================
- Coverage   91.76%   48.99%   -42.78%     
===========================================
  Files         119      120        +1     
  Lines       16615    16662       +47     
  Branches     2796     2801        +5     
===========================================
- Hits        15247     8163     -7084     
- Misses        936     7848     +6912     
- Partials      432      651      +219     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@charles-cooper
Copy link
Member Author

@HodanPlodky pointed out offline -- there could be an msize instruction that this optimization interferes with

for idx, inst in enumerate(bb.instructions):
self.instruction_index[inst] = idx
if inst.opcode == "msize" and bb not in self.reads_msize:
self.reads_msize[bb] = idx
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should not this store last msize in basic block instead of first msize. This could be the problem in case which is showed in PR charles-cooper#53

@harkal
Copy link
Collaborator

harkal commented Dec 9, 2024

Volatile instructions were something temporary until proper effects handling was implemented. Now that the dft pass is doing proper effects analysis and makes use of that information, this elimination should be part of it?

@charles-cooper
Copy link
Member Author

Volatile instructions were something temporary until proper effects handling was implemented. Now that the dft pass is doing proper effects analysis and makes use of that information, this elimination should be part of it?

I think we can generalize the analysis done here but it increases the PR scope

@charles-cooper
Copy link
Member Author

i investigated refactoring (or at least trimming down) VOLATILE_INSTRUCTIONS and replacing it with essentially checking if the instruction is a terminator instruction or has write effects. however, it was not that clean since we still need to special-case MSIZE.

another approach which simplifies the code here would be to have a special volatile instruction like mtouch which has an msize write effect, and then have the frontend issue it specifically when it needs to fence msize. i think this approach is OK - i think the frontend only depends on the "memory reservation" capability of mload (actually iload) in one place.

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.

3 participants