On Fri, Apr 24, 2020 at 08:15:36AM +0200, Richard Biener wrote: > 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 ...
And also, throwing away all existing info way too often. Part of that is causes by the interfaces to DF we have. That shouldn't be hard to fix. But mainly it is because too many things do not keep the info up-to-date after changes. > 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. Depending on the target, almost *everything* depends on how far some code is from other code, and you can get much better code if you know you *are* close. But many passes already are per-BB of course. It's just the hard ones (RA...) that are not local at all. So you'll have to attack IRA if you want DF to be more local only, I think? > And yes, it probably requires a further lowering on GIMPLE to expose things > like multi-reg operations, As I said before, I don't think this is a good idea. > lowered bit-precision arithmetic, lowered But that is :-) > address generation and eventually constant legitimization (introducing a > constant pool already on GIMPLE, ideally maintaining it in the symbol > table). That might work on some targets, sure :-/ Segher
