This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] Illegible dumps with dump_cfg_function_to_file


Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> writes:

| Hello,
| 
| > > > Why did you introduce this new function instead of using
| > > > dump_function_to_file?
| > > 
| > > Because it no longer works after cfg creation (or perhaps it does just
| > > now, but will not quite soon, and it anyway seems better to me to use
| > > an intermediate-represenation independent solution).
| > > 
| > Which is what dump_function_to_file should be.  To get consistent
| > visuals, we need to have a single point of entry to the dumpers. 
| > dump_function_to_file should be able to tell whether the function has
| > been hacked into basic blocks.  We should not have two different
| > function dumpers.  There's going to be code duplication problems and
| > visual consistency problems, making it hard to diff between different
| > passes.
| 
| OK, but IMHO the right way is what dump_cfg_function_to_file does, since
| it is infrastructure independent.  dump_function_to_file is only useful
| before we switch to cfg based representation.

an opinion of someone who does not know th exact details of tree-ssa.
I believe it is better to have a single entry-point and use flags
(i.e. parameters) to vary on output.  That usually reduces codes
duplication.  (I have been always worried that tree-ssa duplicated the
mess in cp/error.c).

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]