[Mlir-commits] [mlir] [mlir] [dataflow] further optimize dataflow compile time (PR #149804)

[donald chen]

cxy-1993 wrote:

> > > I still don't understand your usecase, sorry. What do you mean by "require maintaining an additional analysis"? Are you using upstream analyses? Which ones? If not and you have a custom downstream analysis, you already derived from `DenseAnalysis` so you can add the `irrelevantPoints` map and `processOperation` there, without modifying the core.
> > 
> > 
> > In our downstream llvm, we added irrelevantPoints directly to DenseForwardAnalysis/DenseBackwardAnalysis to reduce compile time. Many of our analyses are based on dense dataflow analysis, and I don't want to add the same code to every single one.
> 
> I see. I'm still concerned this code is adding (small) overhead for all dataflow analysis users, even if they don't need the `irrelevantPoints` feature. What we can do instead is to add (either upstream or downstream) another classes deriving from `DenseForwardAnalysis`/`DenseBackwardAnalysis` which adds the `irrelevantPoints` map and `processOperation` override and then you can derive from them instead. What do you think?
> 
> CC @Mogball @ftynse

I understand your concern. Inheriting a new class purely for a set's average O(1) lookup time doesn't seem very essential. I'd like to get @Mogball  @ftynse  opinions on this. 

https://github.com/llvm/llvm-project/pull/149804