Re: Plan for removing global state from GCC's internals

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Thu, 27 Jun 2013, David Malcolm wrote:

> I want to focus on "removal of global state", and I want that to be
> separate from "cleanups of internal APIs".

Whereas I'm thinking of global state as being a symptom of a problem - 
messy interfaces that have accreted over time - rather than the problem in 
itself.  And moving things into "universe" allows a proof-of-concept of a 
shared library build (much like Joern's multi-target patches with 
namespaces three years ago provided a proof-of-concept of a multi-target 
build) without really addressing the real problem (basically, I think of 
state in "universe" as effectively being global state, and moving state 
into something passed down to the places needing it - only the relevant 
bits of state, not a whole universe pointer if there's a smaller logical 
unit - rather than just accessed through TLS, as being the point where 
global state is *really* eliminated).

Now, the bulk conversion to universes seems a lot more maintainable than 
Joern's multi-target patches, and a lot more plausibly an incremental step 
to a proper fix, and so a lot more reasonable to go in as an incremental 
step, but I'd still think of it as one of the infamous partial transitions 
in the absence of a reason to believe, for each formerly-global object 
being accessed via the universe (or some other piece of context), that 
it's being accessed via the right piece of context being passed down to 
functions that need it, rather than from the global universe for something 
that doesn't need to be.

As for accessing globals directly versus via APIs: yes, I suppose you do 
still have an access to a global class instance in each place you formerly 
had a global variable (that's now a member of that class), so by itself 
such a conversion to a better API doesn't reduce the number of global 
variable accesses, just improves the interface in other ways - and it's 
the changes to pass a pointer to an instance around that reduce the global 
state usage.  In the case of dump files, pass-local state may be a better 
place than the universe to keep the instance - it is after all passes.c 
that calls dump_start / dump_finish.

(Indeed, it would arguably be an improvement, in cases where an API uses 
global state completely implicitly as opposed to via a class instance that 
contains that state, to pull out that global state to the call sites, 
reflecting that eventually those call sites should be passing in proper 
non-global values.  For example, converting those diagnostic function uses 
that implicitly use input_location to use it explicitly instead - each 
should eventually move to an explicit location that isn't input_location.  
Implicit use of global_dc matters rather less and it seems reasonable 
enough for that context to continue to come from the universe in many 
cases.  Cf. how a couple of years ago I made a lot more option-handling 
code pass around struct gcc_options *, location_t and diagnostic_context * 
values, rather than directly using the globals - although at some point, a 
global value tends to get passed into these functions.)

(Similarly, for target macro to hook conversions (a) I consider a function 
in targhooks.c that uses the target macro just to be an interim step and a 
macro only really to be addressed once all the definitions in different 
targets have been converted to define functions and the macro has been 
poisoned, and (b) for each such conversion we at least consider what the 
hook ought to look like rather than presuming a direct conversion of the 
macro semantics, one macro to one hook, is appropriate.)

-- 
Joseph S. Myers
joseph@codesourcery.com