On Wed, 15 Jan 2014, Steven Bosscher wrote: > On Wed, Jan 15, 2014 at 11:52 AM, Richard Biener wrote: > > I can split off a df_analyze_1 and have a df_analyze () doing what > > it does now and a df_analyze_loop () combining df_set_blocks () > > and df_analyze () for example. > > df_analyze_loop sounds good to me. > > But shouldn't it be possible to avoid the re-computation of the > pre/postorders? If the CFG hasn't changed, the orders also haven't > changed. It should be possible to communicate that to DF from the CFG > hooks somehow.
But in these cases it doesn't really help as the pre/postorders are pruned to the sub-CFG (so they are lost). But yeah, with more refactoring in this area this could be improved. > AFAIR loop-invariant.c doesn't modify the CFG (and if it does then > it's easily avoided) and RTL loop unswitching should just go away. Right. Even better would be if loop-invariant.c could keep the DF info up-to-date. After all it just moves stmts and seems to be interested in UD chains only ... (which shouldn't change at all?) Richard.
