Dataflow Analysis Framework

[axelcool1234]

The following is a dataflow analysis framework based off the C++ MLIR implementation.

An analysis I've implemented on top of the framework is SCCP: #456

[axelcool1234]

Wishlist:

• A way to check if an op is a "branching" one. Parallel to MLIR's RegionBranchOpInterface
• A way to check if an op is a callable one. Parallel to MLIR's CallableOpInterface
• A constant folder
• replaceAllUsesWith
• replaceWithConstant

Without the first three, I have to manually write out the ops I know that fits them. I already did so for SparseConstantPropagationAnalysis with manual constant folding.

I need a way to see if an op is region branching or callable to complete DeadCodeAnalysis and SparseForwardDataFlowAnalysis.

These are the last of the hurdles before I have a working SCCP transform :)

Other things I need to investigate:

• DeadCodeAnalysis deals with symbol tables. Not sure what that's about - our codebase doesn't have any of that. Not sure if it's necessary at this stage.
• DeadCodeAnalysis stores an analysisScope object. DataFlowAnalysiss are usually without state. Not sure if there's a way around this - need to look more into the purpose of this object.

Other things I have to do:

• Better documentation (also deal with writing doc comments instead of regular comments)
• Write a guide for John so he can try implementing KnownBits.

[math-fehr]

Sorry for the delay!
I think what would help a lot reviewing this is adding more documentation on the later part of the Veir/Analysis/DataFlowFramework.lean file.
Maybe adding a markdown documentation (/-! -/) at the beginning of the function to explain the relationship between the different structures?

Otherwise, the main issue I see right now is the structures that are using your Dynamic types. Do you think you can see a way to define them with a mutual somehow? If you don't, we can try to look into it.

[axelcool1234]

Thank you for the review comments. I'll try to get back to them as soon as I can (my laptop decided to have some hardware issues so it might be a second, but I will get to them). I apologize for the poor documentation (I'm still getting used to collaborating with others - didn't have much of that at this scale in my undergrad unfortunately). I should've done an additional once over my PRs and ensure I've commented on everything for better clarity. I'll make sure to do that as well.

I will also reconsider the structure of the framework as a whole now that I have a strong understanding of how the original MLIR version that this is mirroring works. I have a couple of ideas of some restructuring that should eliminate the strange hacks/workarounds and make this simpler. Once I get my laptop up and working I will work on a proposal for this via an additional commit.

[axelcool1234]

@math-fehr @ineol I have pushed the changes I've mentioned in our last meeting! This should be cleaner I hope.

I think I need to think about how to organize the Analysis/ folder - I currently have this strange split between DataFlowFramework.lean and Facts.lean (which is a misleading name for the file as it's doing more than just fact related stuff) to prevent import cycles.

[math-fehr]

Nice! It looks much much better now!
I just added comments mostly about documentation and naming!

I guess to me the biggest question is wether or not some class should be structure instead, like HasFactKind (which I'm not 100% sure I understand what it does). Other than that, the structure looks good now to me!

[math-fehr]

Okay that looks much much better again, nice!
I added some comments for documentation (mostly places where I feel it is harder to understand what's going on).
I'll wait that @ineol reviews it (probably early next week), and to me that should be probably good to go after that!