On Thu, Oct 20, 2011 at 10:36 AM, Basile Starynkevitch <bas...@starynkevitch.net> wrote: > On Thu, Oct 20, 2011 at 10:21:27AM +0200, Richard Guenther wrote: > >> I'd rather have a way to make dump-files more structured (so, following >> some standard reporting scheme) than introducing yet another way >> of output. [after making dump-files more consistent it will be easy >> to revisit patches like this, there would be a natural general central >> way to implement it] > > I'm not sure to understand what more structured dump-files mean. Are you > thinking of making them in XML or in JSON format (both requires some minimal > structure).
No, with structured I mean passes should dump things in a common format. Which in the end is achieved most easily by providing some helpers that take care of the formatting details. Consider the various ways passes dump that they simplified a statement. Or the various ways passes dump a kind of lattice they computed for all SSA names, or how they dump information on some loop. > >> So, please fix dump-files instead. > > I'm not sure to understand what that means, because I am not sure to grasp > the intended meaning and roles of dump files (in particular, from a plugin > point of view). And I'm not sure to understand what fixing them means. I don't see how plugins come into the picture here or how they should be any different from the core compiler. > > My incomplete understanding is that dump files are for any kind of > GCC-debugging (or GCC-plugin-debuggging) output which any pass might feel > useful, but that is probably too weak as a definition. Or are dump files > something more precise that that? No, that's exactly what they are about. They are already structured by means of the dump-file modifiers (the TDF_ flags), so you can already filter the output. It should be simple to extend this, and at the end, select a part of the output to stdout as well. Richard.