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
