Re: [patch] Reorganization of dump flags

[Diego Novillo <dnovillo at google dot com>]

On 22-Sep-07, at 17:46 , Zdenek Dvorak wrote:

> Whether or not the information corresponding to a given dump keyword
> will be shown may be specified by an option, e.g., if I would like to
> see just scev-related information of medium importance or higher, I
> would use
>
> -fdump-tree-all-scev/2

Wouldn't this be -fdump-tree-scev/2?

> Additionally, there are some options that do not specify what
> information will be dumped, but affect its formating (TDF_BLOCKS,
> TDF_VOPS, TDF_STMTADDR and such).  We do not use keywords for  
> these, but
> instead we just keep their bitmap as we do now (so they do not have  
> the
> four levels, they can be just on or off) -- I will call these "dump
> qualifiers". This makes it possible to use the qualifiers in the same
> way as it is done now, pass their sets as function arguments, alter it
> locally, etc.  The dump flags that are only used internally (TDF_TREE,
> TDF_RTL, ...) are handled the same way, except that we do not  
> assign any
> option for setting them.

Sorry, I'm lost.  You are saying that these qualifiers are specified  
exactly as before?
So, if I want medium-level details on scev and blocks and vops I say:

-fdump-tree-scev-blocks-vops/2?

I like the idea of this patch quite a bit, but I think that we need  
to sanitize the syntax we use to specify dump options.  It's gotten  
to be a bit bizarre. How about a more structured syntax?

-fdump-tree-<pass>[-level={0,1,2,3}][-options= 
{blocks,vops,stmtaddr,...}]

Where 'pass' is 'all' or any of the names of the individual passes we  
have today.
'level' is one of the three levels of details that you introduced in  
this patch.
'options' is one of the TDF_* flags that affects the formatting of  
the output.

Perhaps 'pass' could be made to group various passes, or we could  
allow specifying several passes in the same string.  But I would  
prefer to keep the dumping flag as simple as possible.  We can always  
string several -fdump-tree... together instead of making a single  
long dump switch that gets difficult to parse visually.

As to whether this patch is suitable for this stage.  I agree with  
you that it's going to be unpleasant to maintain until next stage 1.   
It should be safe to apply now, but I would rather defer the decision  
to Mark.