Re: [PATCH 012/236] Convert DF_REF_INSN to a function for now

[David Malcolm <dmalcolm at redhat dot com>]

On Tue, 2014-08-12 at 15:20 -0600, Jeff Law wrote:
> On 08/06/14 11:19, David Malcolm wrote:
> > DF_REF_INSN looks up the "insn" field of the referenced df_insn_info.
> > This will eventually be an rtx_insn *, but for now is just an rtx.
> >
> > As further scaffolding: for now, convert DF_REF_INSN to a function,
> > adding a checked downcast to rtx_insn *.  This can eventually be
> > converted back to macro when the field is an rtx_insn *.
> >
> > gcc/
> > 	* df-core.c (DF_REF_INSN): New, using a checked cast for now.
> > 	* df.h (DF_REF_INSN): Convert from a macro to a function, so
> > 	that we can return an rtx_insn *.
> >
> > /
> > 	* rtx-classes-status.txt: Add DF_REF_INSN.
> OK.

Thanks.  Although this function gets converted back to a macro in patch
191, I just realized that in the meantime that it's not inlined, as is
the case for some of the other macro->function conversions in patches
13-16.

Do I need to convert them to inline functions with the appropriate
headers, and is that regarded as a sufficiently trivial fix to the stuff
you've already reviewed to not need re-review? (I will bootstrap&test).

Or is it OK to suffer the performance hit as the patchkit lands, before
they all become macros again in phase 4 of the patchkit?

Note also that Jakub expressed concern about the effect of all these
inline functions on the debugging experience, and there's this patch
(awaiting review) which I believe addresses that:
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00743.html

Presumably similar changes to gdbinit.in should occur for the relevant
headers (e.g. df.h in this case, though possibly targeted to just the
new function - there are already quite a few inline functions in df.h)

Dave