This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Plan for removing global state from GCC's internals
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: David Malcolm <dmalcolm at redhat dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Mon, 1 Jul 2013 19:43:14 +0000
- Subject: Re: Plan for removing global state from GCC's internals
- References: <1372272382 dot 1022 dot 26 dot camel at surprise> <Pine dot LNX dot 4 dot 64 dot 1306262002150 dot 30407 at digraph dot polyomino dot org dot uk> <1372295735 dot 1022 dot 72 dot camel at surprise> <Pine dot LNX dot 4 dot 64 dot 1306271425010 dot 4602 at digraph dot polyomino dot org dot uk> <1372360959 dot 1789 dot 32 dot camel at surprise> <Pine dot LNX dot 4 dot 64 dot 1306271933460 dot 10184 at digraph dot polyomino dot org dot uk> <1372699842 dot 1789 dot 144 dot camel at surprise>
On Mon, 1 Jul 2013, David Malcolm wrote:
> > 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.
>
> So a pass instance should have its own dump_flags, and various dump
> methods? Perhaps, but as before, I'd prefer to fix the state issue
Yes (or rather, the pass instance should contain an instance of the dumper
class, which in turn has dump_flags and dump_file members) - as far as I
can tell, the lifetime of dump_file and dump_flags is already basically
per-pass rather than global.
> Would you be in favor killing off these macros:
> #define input_line LOCATION_LINE (input_location)
> #define input_filename LOCATION_FILE (input_location)
> #define in_system_header (in_system_header_at (input_location))
> with patches that make the usage of "input_location" explicit? (by
> replacing all uses of these macros with their expansions, cleaning up
> line-wraps as needed).
Yes.
> The only other macro that implicitly uses input_location is
> EXPR_LOC_OR_HERE; that could be removed in favor of:
> EXPR_LOC_OR_LOC(expr, input_location)
> again making input_location explicit.
(I suspect then eliminating the input_location from this - ensuring all
expressions have meaningful locations so EXPR_LOC_OR_LOC isn't needed at
all - will depend on Andrew MacLeod's proposal. It doesn't explicitly
mention this, but one thing that would be desirable as part of making
front ends generate internal representation closer to the source would be
explicitly representing locations for constants, and for references to
declarations within expressions, so that everywhere that wants a location
for an expression can reliably extract one from it rather than finding
there is no location because certain expressions are shared.)
--
Joseph S. Myers
joseph@codesourcery.com