On Thu, Apr 23, 2020 at 4:54 PM Eric Botcazou <botca...@adacore.com> wrote: > > > > > What is wrong with DF? > > > > > > It's slow and memory hungry? > > > > Very true, of course. But can this be significantly better? > > That's a good question worth investigating in my opinion, because DF didn't > quite achieve its initial goal of replacing all the custom liveness analysis > passes only because of its performance; the rest is quite neat. But IIRC > long-time GCC hackers were involved in it, so it was probably tuned already.
Having looked at DF a few times one of its problems seems to be too much indirection in its data structures which is probably a fallout of making it on-the-side rather than a part of the core RTL data structures (like SSA and immediate uses are on GIMPLE). But then where it blows up is usually during computing of the dataflow problems to create those data structures and there's little room for improvement because it deals with a more complex problem than we have on the GIMPLE side. But passes are also mindlessly throwing 'compute-me-everyting' flags at it without really thinking what they need, so ... In the end I question the need of true "global" optimization passes on the RTL IL. Almost everything should be local to interesting-CFG-shape regions. And yes, it probably requires a further lowering on GIMPLE to expose things like multi-reg operations, lowered bit-precision arithmetic, lowered address generation and eventually constant legitimization (introducing a constant pool already on GIMPLE, ideally maintaining it in the symbol table). Richard. > -- > Eric Botcazou
