[PATCH 0/2] Proof-of-concept towards removal of the "cfun" global

[Jeff Law]

On 05/25/2013 07:02 AM, David Malcolm wrote:
> I can think of three approaches to "cfun":
> (a) status quo: a global variable, with macros to prevent direct
>      assignment, and an API for changing cfun.
> (b) have a global "context" or "universe" object, and put cfun in
>      there (perhaps with tricks to be able to make this a singleton in a
>      non-library build, optimizing away the context lookups somehow
>      - see [2] for discussion on this)
> (c) go through all of the places where cfun is used, and somehow ensure
>      that they're passed in the data they need.  Often it's not the
>      function that's used, but its cfg.
I'd think B or C is going to be the way to go here.  B may also be an 
intermediate step towards C.

>
> One part of the puzzle is that various header files in the build define
> macros that reference the "cfun" global, e.g.:
>
>    #define n_basic_blocks         (cfun->cfg->x_n_basic_blocks)
>
> This one isn't in block caps, which might mislead a new contributor into
> thinking it's a variable, rather than a macro, so there may be virtue in
> removing these macros for that reason alone.  (I know that these confused
> me for a while when I first started writing my plugin) [3]
There's a few of these that have crept in over the years. 
n_basic_blocks used to be a global variable.  At some point it was 
stuffed into cfun, but it was decided not to go back and fix all the 
references -- possibly due to not wanting to fix the overly long lines 
after the mechanical change.

>
> I notice that we're constantly accessing:
>
>    some loop
>      {
>        ...
>        use cfun->cfg->x_some_field;
>        ...
>      }
>
> Would it potentially be faster to replace some of these with:
>
>    control_flow_graph &cfg = *cfun->cfg;
>    some loop
>      {
>        ...
>        use cfg.get_some_field () // assuming inlining of accessor
>        ...
>      }
>
> to avoid constantly derefing cfun->cfg?  (That said, would
>   -fstrict-aliasing
> be able to note that cfun->cfg doesn't change, or in a non-LTO build I'm
> guessing it can't make that assumption if the loop calls into functions it
> can't see inside?).
Depends on the context.  If there's a function call in the loop, then 
we're pretty much screwed.  If we're using cfun->cfg regularly in the 
loop, my tendency is to go ahead and manually pull it out of the loop.

Jeff