This is the mail archive of the
mailing list for the GCC project.
Re: New dump infrastructure
- From: Georg-Johann Lay <avr at gjlay dot de>
- To: Sharad Singhai <singhai at google dot com>
- Cc: gcc <gcc at gcc dot gnu dot org>, David Li <davidxl at google dot com>, Richard Biener <richard dot guenther at gmail dot com>
- Date: Wed, 17 Oct 2012 08:17:42 +0200
- Subject: Re: New dump infrastructure
- References: <CAKxPW66qc3be22Ou=+NKF0e5_xdzTqdz_6trz3xoG-uBqz2ViA@mail.gmail.com>
Sharad Singhai schrieb:
I have enhanced the dump infrastructure in r191883, r191884. These
patches updated the tree/rtl dump facility so that passes do not
reference the dump file directly, but instead use a different (and
hopefully cleaner) API.
Instead of this
fprintf (dump_file, ...);
the new style looks like this
if (dump_kind_p (...))
Since the number of existing dump call sites is quite large, currently
both old *and* new schemes are in use. The plan is to gradually
transition passes to use the new dump infrastructure and deprecate the
old dump style. This will also provide better optimization reports in
How are dumps from the backend handled then?
For example, SPU uses fprintf to dump_file.
A backend can easily add additional information to dump files by using
printf or putc or print_inline_rtx or implement whatever own %-codes to
neatly print information.
How will that work after the old interface has been deprecated?
Will there be %-Hooks similar to targetm.print_operand?