On Tue, Oct 16, 2012 at 11:17 PM, Georg-Johann Lay <a...@gjlay.de> 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",
INSN_UID (insn),
insn_data[INSN_CODE(insn)].name,
p, t[p]);
can be rewritten as
if (dump_kind_p (TDF_RTL) && INSN_P (insn))
dump_printf ("i%d %s %d %d\n",
INSN_UID (insn),
insn_data[INSN_CODE(insn)].name,
p, t[p]);
>
> 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.
Thanks,
Sharad
>
> Johann
>
