On Wed, Oct 17, 2012 at 1:40 PM, Sharad Singhai <sing...@google.com> wrote:
> 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.
>
After all the conversion is done, 'dump_file' should go away (by hiding it).
David
> Thanks,
> Sharad
>
>>
>> Johann
>>
