Re: [dataflow] PATCH committed to fix debugging info.

[Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>]

> The solution to these problems is that df privately has a pointer to the
> latest df instance created that it makes available to the dumpers and
> that a new TODO was created to call df_finish on this instance after the
> dumpers have run.  Thus, most of the calls to df_finish have been
> replaced by additions of this flag to the pass manager structure. 
>   
Hi Kenny, I'm sorry to say that I don't like this aspect of this patch 
(I like the rest pretty much).

I don't like, even though there is no need for it right now, that the 
creation of data flow objects cannot be nested.  At the very least this 
should be documented -- and it is not mentioned actually in your 
message, which only refers to the "latest" df instance.

TODO_df_finish is too pervasive IMHO.  Besides, if passes have to 
declare that they need destruction of the dataflow object, this should 
be linked to the "properties" system: after a pass that "destroys" a new 
property PROP_df, the pass manager will call df_finish.

I propose these changes.

1a) The PROP_df scheme proposed above is implemented.  Passes that have 
TODO_df_finish get PROP_df both in "provided" and "destroyed" 
properties.  In the future, in the presence of subpasses these could 
have PROP_df in the "required" properties, rather than in the "provided" 
or "destroyed".

1b) Alternatively, we could have df_finish do nothing if there is no 
"live" dataflow object: this allows it to be called unconditionally from 
the pass manager.  TODO_df_finish could then be removed.  Personally, I 
prefer option 3a.

2) optional: it is allowed to nest the creation of data flow objects.  
The innermost one is stored into a global variable (and updated in 
df_finish) for the dumping system's perusal.  The outermost one does not 
need to be destroyed with df_finish, because the pass manager takes care 
of it (bullets 1a/1b above).  struct df will gain another field, the 
pointer to the outer struct df.

3) anyway, the parameter to df_finish is actually not necessary, either 
because there is only one dataflow object, or because we require that 
calls to df_init and df_finish be nested appropriately.  This would 
remove the need for passes.c to "see" the global variable 
df_current_instance, which can become static indeed.

What do you think?  If you want, I can take care of implementing this 
myself.

Sorry to be a pester -- I'm just trying to anticipate possible 
objections to make the merging of the branch easier when it'll be time 
to do so.
> Also, as Bonzini has suggested, the df_clrur problem was renamed to df_live.
>   
Nice, thanks.

Paolo