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

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Richard Guenther wrote:
> On 7/28/06, Daniel Berlin <dberlin@dberlin.org> wrote:
>> Paolo Bonzini wrote:
>> >> 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.
>>
>> Sure it can.  It's just that if you have one long running instance, this
>> is the way to clean it up.
>>
>> If you want to make it a property instead of a todo flag, go for it, i
>> don't see too much difference here (prop flags don't allow you to nest
>> either).
>
> In general property flags makes sense for information that is created in
> a different pass than it is destroyed.  I don't see that we want df
> information shared between passes?
>
> Richard.
There is currently one case where df must stay live between passes. 
There is one instance of df for local, global and reload.  Also the way
that the schedulers share information means that one instance is created
in some scheduler and someone else is required to tear it down.  The
instance does only last for one pass, but it is quite convoluted to
follow this.

However, asside from this, they are created and destroyed in a single pass.

I should admit that I do not like what I did here.  I considered the two
alternatives of doing it the way that I did and just having the passes
that use df call the dumper on their own rather than using the todo
flag.  Danny and I liked the former slightly better. 

While I agree that my solution does not allow nested instances of df. 
However, I actually think this is a feature rather than a bug.  One of
the long term problems with df which we inherited from the original
design is that it is expensive to keep building and tearing down the
scanning.  At some point want to keep open the option that we attach the
scanned info to the insn's and just keep it up to date as the insn's
change.  Having nested instances of df will only make this harder. 

If the idea here is that we want to add another todo flag to create a df
instance and a call to get this from the pass manager.  I think that
this is what Paolo is asking for, but I am not a pass manager expert. 
However, there are currently flags to df_init that effect the scanning
so this is going to have to be thought out carefully. 

I am open to changes here, but I would like to see something that is
clearly better. 

Kenny