On Mon, 9 Dec 2013, David Malcolm wrote: > On Fri, 2013-12-06 at 21:27 +0100, Richard Biener wrote: > > Oleg Endo <oleg.e...@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
fundef_no_for_fn (cfun) > #define current_loops loops_for_fn (cfun) > #define dom_computed less obvious - we have DOM info computed only for a single function throughout the compilation (so rooting DOM info from struct function is somewhat odd). I wouldn't touch it unless the DOM API gets a _fn API variant (if that is desired at all). > #define n_bbs_in_dom_tree Likewise. As of using more C++ I was thinking about providing context by means of adding accessors to gimple_opt_pass that automagically provide the 'cfun' argument. That of course means making passes really classes derived from gimple_opt_pass. The idea is that from being a gimple_opt_pass you know you are working with a single function (and the pass instance can have a pointer to it, to get rid of 'cfun') and that there should be a convenient API to use from such context where the function you work with is implicit. Of course that would overload gimple_opt_pass with various API wrappers (or we'd use multiple inheritance and API objects). Richard. > 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 > > > -- Richard Biener <rguent...@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer
