refactor[venom]: introduce IRContext and IRAnalysisCache

[harkal]

What I did

This PR completes a big refactor of the venom codebase, while introducing IRContext and IRPassManager.
IRContext is now encapsulating the whole Venom context of compilation which now contains all the IRFunctions.
The pass manager IRPassManages attempts to clean up the pass/analysis handling, by providing a way for passes to request and retrieve specific analyses over the Venom code.

How I did it

How to verify it

Commit message

Add the implementation if `IRContext` and `IRPassManager` along with the required refactoring

Description for the changelog

Cute Animal Picture

[charles-cooper]

i think overall this is a big improvement - the passes are more encapsulated.

question: why do request_analysis and invalidate_analysis have to be called imperatively? is there any way for a pass to register which analyses it needs and then there is automated machinery which calls request_analysis and invalidate_analysis?

[charles-cooper]

removing this loop seems to cause an optimizer regression

[harkal]

This depends on the compiled code. For example compiling CurveStableSwapNG-0.4.0.vy results (wc -c):

master branch: 50489
Current branch: 50541 <-- indeed looks like a regression

but on the current branch if we just remove DFTPass at the end like so:

@@ -49,7 +49,7 @@ def _run_passes(fn: IRFunction, optimize: OptimizationLevel) -> None:
 
     SimplifyCFGPass(pm).run_pass()
     RemoveUnusedVariablesPass(pm).run_pass()
-    DFTPass(pm).run_pass()
+    # DFTPass(pm).run_pass()

we get down to size that master can't get to: 50419

This PR is about getting the code cleaned up and organized by providing the machinery to have pass/analysis flexibility (while also making it much more efficient 🚀 ), and then the exact sequencing of passes, along with tuning them, will be determined as a separate issue.

[charles-cooper]

well, adding the loop back in reduces codesize again -- 50417

[charles-cooper]

i guess the RemoveUnusedVariablesPass as currently implemented is not really a one-shot pass, since each iteration can remove more dead variables

[harkal]

question: why do request_analysis and invalidate_analysis have to be called imperatively? is there any way for a pass to register which analyses it needs and then there is automated machinery which calls request_analysis and invalidate_analysis?

I tried both designs, but the imperative won at the end. It's more clear/explicit when and how request and invalidations happen, and it gives you the flexibility of sequencing and re-requesting analyses when needed depending on the nature of the pass.

[charles-cooper]

and it gives you the flexibility of sequencing and re-requesting analyses when needed depending on the nature of the pass.

like here? https://github.com/vyperlang/vyper/pull/3983/files#diff-014351fadf932e6f54253bd6705a6b85dda68db2e9ac7daa6aad133bc2253217R71

[charles-cooper]

it will be nice to have vyper/venom/analysis/__init__.py which exposes the classes, so we don't need to import each class from the specific module

[charles-cooper]

unenecessary constructor implementation

[charles-cooper]

useless constructor

[charles-cooper]

useless constructor implementation

[charles-cooper]

maybe entry_block?

[charles-cooper]

or entry_point

[charles-cooper]

should we just delete the comment then?

[charles-cooper]

i think this is redundant, because remove_unreachable_blocks() also gets run in SimplifyCFG pass

[charles-cooper]

this looks very closely coupled to IRAnalysis. maybe it should go in the same file, and also be renamed to IRAnalysisManager

[charles-cooper]

doesn't super().invalidate() throw an exception?

[charles-cooper]

note: large contracts i was testing come from 24s to ~6-7s(!)

[charles-cooper]

nice work -- very nice cleanup. merging, although i think we need to do a follow-up PR to investigate the tuning issues as discussed here #3983 (comment)