* Re: new patches using -fopt-info (issue5294043)
[not found] ` <CAFiYyc2S=c7yHJE1U-g7AO=a_uA44=aM0-wxOpHfiq-HRg-WjA@mail.gmail.com>
@ 2011-10-20 8:53 ` Basile Starynkevitch
2011-10-20 12:05 ` Richard Guenther
0 siblings, 1 reply; 2+ messages in thread
From: Basile Starynkevitch @ 2011-10-20 8:53 UTC (permalink / raw)
To: gcc
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).
> 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.
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? In particular, should a dump file contain
textual descriptions of GCC data useful to its pass [e.g. some "input"
representation], or only modified by that pass [e.g. some representation of
the passe's "output" or side-effect]?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: new patches using -fopt-info (issue5294043)
2011-10-20 8:53 ` new patches using -fopt-info (issue5294043) Basile Starynkevitch
@ 2011-10-20 12:05 ` Richard Guenther
0 siblings, 0 replies; 2+ messages in thread
From: Richard Guenther @ 2011-10-20 12:05 UTC (permalink / raw)
To: Basile Starynkevitch; +Cc: gcc
On Thu, Oct 20, 2011 at 10:36 AM, Basile Starynkevitch
<basile@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.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-10-20 8:52 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20111019232801.3532EC1F62@rong.mtv.corp.google.com>
[not found] ` <m21uu8zhdl.fsf@firstfloor.org>
[not found] ` <CAFiYyc2S=c7yHJE1U-g7AO=a_uA44=aM0-wxOpHfiq-HRg-WjA@mail.gmail.com>
2011-10-20 8:53 ` new patches using -fopt-info (issue5294043) Basile Starynkevitch
2011-10-20 12:05 ` Richard Guenther
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).