Re: [PATCH 10/13] Eliminate last_basic_block macro.

[David Malcolm <dmalcolm at redhat dot com>]

On Fri, 2013-12-06 at 21:27 +0100, Richard Biener wrote:
> Oleg Endo <oleg.endo@t-online.de> wrote:
> >On Fri, 2013-12-06 at 16:57 +0100, Steven Bosscher wrote:
> >> On Fri, Dec 6, 2013 at 3:51 PM, David Malcolm wrote:
> >> >         * asan.c (transform_statements): Eliminate use of
> >last_basic_block
> >> >         in favor of last_basic_block_for_fn, in order to make use
> >of cfun
> >> >         explicit.
> >> 
> >> Can we please make all this _for_fn go away?
> >> 
> >
> >Sorry if this has been discussed before... but why not adding member
> >functions to 'function' instead of freestanding macros/functions that
> >take a function* as a first argument?  This would also make it easier
> >to
> >eliminate the "_for_fn" (freestanding function/macro name clashes etc)
> >I
> >think.
> 
> Both can be done, but these patches make cfun uses explicit which was the goal while following existing practice.

Yes, longer-term I'd prefer member functions.  The approach I posted
approach gives identical results to the status quo after a trip through
the preprocessor, so is somewhat lower-risk than introducing inlinable
member functions. (and in any case, all of the repeated implicit
dereferencing of "cfun->" seems inefficient to me, but not something I
plan to touch in stage3)

I've gone ahead and committed the patch series to trunk, test-building
before each commit, and fixing up patches 11 and 12 for the issues noted
by Oleg (the config/sh files had .cc suffixes, and hence didn't show up
in my grepping; I updated my grep accordingly).

There are still 4 macros in function.h that implicitly use cfun, which
it's less clear to me how to remove:
        #define current_function_funcdef_no
        #define current_loops
        #define dom_computed
        #define n_bbs_in_dom_tree

plus various other cfun-using macros elsewhere in headers...

FWIW, here are the svn revisions of what I committed, vs the numbering
of the patches in the emails:
  0001: r205816
  0002: r205817
  0003: r205818
  0004: r205820
  0005: r205821
  0006: r205822
  0007: r205823
  0008: r205824
  0009: r205825
  0010: r205826
  0011: r205828
  0012: r205829
  0013: r205830

Hope this is all sane
Dave