Pass Manager for the Sway-IR

[vaivaswatha]

Pass Manager for the Sway-IR

GitHub: #2399

Requirements

• Levels of optimisation mimicking -O0, -Os, -O3, etc.
• Passes which match a category (e.g., constants) could be requested as a group.
• Heuristics for pass ordering / scheduling (the phase ordering problem): Optimisations could be re-run until their returns have diminished below a certain point, or compile time performance limits are met. In what order should passes be run for best code quality?
• 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.
• Printing the IR must also be treated as a "pass" from a command line perspective (not necessarily from the perspective of designing the pass manager), allowing us to print the IR at any point in the pipeline.
• Dependence b/w passes:
  • Hard dependence. If X => Y (Y hard depends on X), then X must be run before Y. This is only allowed when X is
    an analysis and not a transformation.
  • Soft dependence. If X -> Y (Y soft depends on X), then
    running X before Y may improve the quality of generated code,
    but is not necessary for correctness.

Design: Interface

Category

Several categories are defined. Optimization levels -O0, -O1 etc are also
categories. Each optimization pass can list out the set (size >= 0) of categories that it belongs to.

Dependences

Each pass can specify a list of other passes that it depends (hard or soft) on.

• We either use the rust type system or a dynamic check in the pass manager to
  ensure that hard dependences don't form a cycle. (need to think through and decide).
• Cycles in soft dependences are an indication that we may need to run the passes
  till there's no change (or we've met some other criteria such as compile time).

Configuration

The pass manager is invoked with exactly one configuration parameter. A configuration
specifies an ordered list of passes and or catetories of passes to execute. It is
the job of the pass manager to execute these passes as close to the specified order
as can be executed satisfying all dependences.

A debug printer will be provided that prints the final ordered list of passes as
computed by the pass manager, ready for execution.

Design: Internals (working)

TBD

[otrho]

Cool. Two immediate thoughts:

• Does the command line mean arguments to forc build? Is that where we'd want to be able to pass low level stuff like -dce or just higher level categories like -O2?
• How about Forc.toml support? Probably again would only be useful for higher level categories like -Os vs -O2.

Dunno how you'd manage to get a static checker for recursive hard dependencies, but I guess it may be possible 🙂

Otherwise sounds good. It makes the most sense for it to be a part of sway-ir?

[vaivaswatha]

Thank you Toby.

Does the command line mean arguments to forc build? Is that where we'd want to be able to pass low level stuff like -dce or just higher level categories like -O2?

I assumed so, yes. But we could restrict what we expose to forc build if we want to.

How about Forc.toml support?

I hadn't considered this, but I suppose it's going to be straightforward to support this similar to supporting forc build arguments (and likely, they'll be equivalent in what they can express).

Dunno how you'd manage to get a static checker for recursive hard dependencies

You're probably right and it can't be done. It was just a quick thought and I didn't explore it deeply.

Otherwise sounds good. It makes the most sense for it to be a part of sway-ir?

Thank you. Yes, this will be part of sway-ir.

[yegogo3]

no bad for it

[Kleralaut]

Nice

[bunny8347]

faucet not working

[mohammadfawaz]

Cargo.toml supports opt-level = under profiles such as:

[profile.release]
opt-level = 'z' # Optimize for size

We could request that from tooling. Flags for forc build should probably more coarse grain and less technical, such as forc build --release and so on.

Everything else suggested here makes sense to me!

Printing the IR must also be treated as a "pass" from a command line perspective

So is the verifier probably.

On thought: I remember that LLVM had a way to pass in "arguments" to passes. For example, you can run the same pass in the pass manager multiple times but with different parameters depending on the use case. Likely a super low priority thing but could be an interesting tweaking mechanism. May also be useful for tweaking the optimization for various backends.

[vaivaswatha]

Some thoughts / decisions as I'm implementing the pass manager:

Cycles in soft dependences are an indication that we may need to run the passes till there's no change

This may be a bad idea, introducing unnecessary complications. It is simpler to allow only dependences on analyses (what I call as hard dependence above) and ensure no cycles at all. There can never be a dependence on a transform.