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.

Sign up for GitHub

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

Jump to bottom

Create an IR optimisation pass manager. #2399

Closed
otrho opened this issue Jul 28, 2022 · 3 comments · Fixed by #4131
Closed

Create an IR optimisation pass manager. #2399

otrho opened this issue Jul 28, 2022 · 3 comments · Fixed by #4131
Assignees
@vaivaswatha
Labels
compiler: optimization IR Optimization Passes

Comments

@otrho
Copy link
Contributor

otrho commented Jul 28, 2022

As we add new optimisation passes we need a structured way to call them.

Some potential features:

  • Levels of optimisation mimicking -O0, -Os, -O3, etc.
  • Pass categories and metadata:
    • Passes which match a category (e.g., constants) could be requested as a group.
    • Passes which 'request' to be run after a certain operation type. E.g., DCE should always be run after instruction combining since new opportunities may have appeared. Simplify CFG after inlining. This would require a fair bit of design though.
  • Heuristics for deciding what to run:
    • Optimisations could be re-run until their returns have diminished below a certain point, or compile time performance limits are met.

But initially we just need a nice way to say 'optimise this IR at this level' from Sway core.
@otrho otrho added the compiler: optimization IR Optimization Passes label Jul 28, 2022
@otrho otrho mentioned this issue Jul 28, 2022
Open
13 tasks
@otrho
Copy link
Contributor Author

otrho commented Aug 3, 2022

I put something into the opt binary (sway-ir/src/bin/opt.rs) which resembles something we might at least start with.

@otrho otrho mentioned this issue Aug 26, 2022
Open
@vaivaswatha
Copy link
Contributor

vaivaswatha commented Dec 12, 2022 •
edited

More TODOs:

  1. Allow specifying individual passes on the command line. So if no opt level is specified, but -dce is specified, then only DCE must be run.
  2. Printing the IR must also be treated as a "pass" from a command line perspective, allowing us to print the IR at any point in the pipeline.

Passes which 'request' to be run after a certain operation type. E.g., DCE should always be run after instruction combining

  1. We need to have two kinds of dependences here. A hard dependence X->Y (Y hard depends on X) means that Y cannot run without X having run. Hard dependences must be allowed only when X (in the example here) is an analysis and not an optimization. Soft dependences (which need not be enforced, for correctness) can be b/w optimizations. As far as I know LLVM doesn't have this "soft dependence". They just schedule the passes as needed. But I think it's a nice thing to have if we design it all well.

@vaivaswatha vaivaswatha self-assigned this Dec 14, 2022
@vaivaswatha
Copy link
Contributor

Design discussion: #3596 (since GH hasn't added an auto-link).

@vaivaswatha vaivaswatha mentioned this issue Jan 23, 2023
Merged
vaivaswatha added a commit that referenced this issue Feb 7, 2023
@vaivaswatha @mohammadfawaz
A new pass manager (#3856)
4e4d7a6 
The new pass manager replaces the existing one, and also is now used in
the main `forc build` pipeline (the old pass manager was restricted to
the `opt` executable).

It doesn't fully achieve #2399 and #3596 yet. i.e., it doesn't do
automatic dependence resolution and handle categories of passes.

---------

Co-authored-by: Mohammad Fawaz <mohammadfawaz89@gmail.com>
vaivaswatha added a commit that referenced this issue Feb 13, 2023
@vaivaswatha
Pass dependencies and resolution in the pass manager
d78614b 
This PR allows passes to specify dependences on other
(analysis) passes. The pass manager then ensures that
any analysis that a pass depends on is available before
that pass executes.

Tracking issue: #2399.
Design discussion: #3596.

In the next PR under this work, I will introduce
pass groups, allowing easy specification of optimization
levels etc.
@vaivaswatha vaivaswatha mentioned this issue Feb 13, 2023
Merged
7 tasks
vaivaswatha added a commit that referenced this issue Feb 14, 2023
@vaivaswatha
Pass dependencies and resolution in the pass manager (#4067)
f5e2065 
This PR allows passes to specify dependences on other (analysis) passes.
The pass manager then ensures that any analysis that a pass depends on
is available before that pass executes.

Tracking issue: #2399.
Design discussion: #3596.

In the next PR under this work, I will introduce
pass groups, allowing easy specification of optimization levels etc.

Testing: I ensured that the bytecode hashes for all "to pass" tests in
our testsuite remained same with and without this PR.
@vaivaswatha vaivaswatha mentioned this issue Feb 16, 2023
Merged
7 tasks
vaivaswatha added a commit that referenced this issue Feb 16, 2023
@vaivaswatha
Add and create PassGroups (#4099)
307feca 
## Description
Introduce `PassGroup` as a construct to organize passes. Also have
module passes for verifier and printer.

For example, we can now do `opt module_printer dce module_printer <
dce1.ir` that prints the module before and after DCE.

No extra command line flags have been added to `forc`, yet.

#3596, #2399 

Testing: All "should_pass" tests have the same bytecode hash before and
after this change.

## Checklist

- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
@vaivaswatha vaivaswatha mentioned this issue Feb 20, 2023
Merged
7 tasks
vaivaswatha added a commit that referenced this issue Feb 20, 2023
@vaivaswatha
Provide opt options for verify and print after each pass (#4131)
091b9a8 
## Description
This doesn't add any new option for `forc`. At the moment we have just
`-O1` and I believe that can stay as the default without additional
flags. We have the infrastructure now to add more optimization levels
and options with the new pass manager, and hence add the actual `forc`
options when necessary.

Closes #2399

## Checklist

- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@vaivaswatha vaivaswatha

Labels
compiler: optimization IR Optimization Passes
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Provide opt options for verify and print after each pass FuelLabs/sway
2 participants
@otrho @vaivaswatha