This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New dump infrastructure


On Tue, Oct 16, 2012 at 11:17 PM, Georg-Johann Lay <avr@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
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]