This is the mail archive of the
mailing list for the GCC project.
Re: New dump infrastructure
On Tue, Oct 16, 2012 at 11:17 PM, Georg-Johann Lay <email@example.com> wrote:
> How are dumps from the backend handled then?
I haven't really looked at backends. Perhaps they can be converted at
the cost of extra dispatch functions defined in dumpfile.c. For
example, we can add methods like 'dump_rtl_single ()' and
'dump_inline_rtx ()' to the dump interface.
> For example, SPU uses fprintf to dump_file.
These call sites should be easier to handle. For example, the
following fragment from config/spu/spu.c:spu_sms_res_mii
if (dump_file && INSN_P (insn))
fprintf (dump_file, "i%d %s %d %d\n",
can be rewritten as
if (dump_kind_p (TDF_RTL) && INSN_P (insn))
dump_printf ("i%d %s %d %d\n",
> 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.
Not all of the use cases you mention need to be converted. I was
rather more interested in distilling high-level optimizations.
However, I suspect even in the backends, some sites might benefit by
converting them into -fopt-info format.
> How will that work after the old interface has been deprecated?
> Will there be %-Hooks similar to targetm.print_operand?
The dump_file is not going away, only the way to access it would change.