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

Separate "dead-code-elimination" from constant folding #1807

Open
doug-q opened this issue Dec 18, 2024 · 0 comments · May be fixed by #1902
Open

Separate "dead-code-elimination" from constant folding #1807

doug-q opened this issue Dec 18, 2024 · 0 comments · May be fixed by #1902
Assignees

Comments

@doug-q
Copy link
Collaborator

doug-q commented Dec 18, 2024

the constant folding pass includes a "dead-code-elimination" phase at the end. Let's extract this into a separate pass. Constant folding can (perhaps optionally) invoke that pass.

Problems with the existing dead code elimination in constant folding:

  • We need a notion of public function for the "roots" of the pass. constant folding: FuncDefns and FuncDecls are not considered needed #1797
  • We follow edges back from roots.
    • There is a special case for CFG edges, perhaps this should be cleaned up.
    • This means an order edge from an op to an output node keeps the op alive, but an order edge from an input node to an op does not keep that op alive. This seems wrong.
    • We have no explicit notion of ops having "side effects". However they can be simulated with order edges from that op to the output node for example:
      • a panic op with no neighbours is considered dead.
      • A call node is dead if it has no out neighbours.
    • a QFree with no order edge to the output is dead by this definition. The graph will end up invalid, with unused linear ports
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 a pull request may close this issue.

2 participants